Ask HN: An Acceptable Erlang
33 comments
Reia:
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.
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.
LFE is still very much alive and I work on it when I have the time.
Also check out Elixir (https://github.com/josevalim/elixir) or Efene (https://github.com/marianoguerra/efene).
Ah, Reia and Elixir both look great, thanks for these.
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.
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.
Erlang very purposefully has very very little syntax, it may seem unfamiliar and some people may always see it as ugly however once you figure out where the commas and semi colons go you are pretty much done learning the language.
And 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.
And 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.
The Erlang syntax isn't that bad. Don't be intimidated by it. You mention the line ending punctuation as a specific cause of concern which is difficult to learn. Let me try to help:
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.
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.
[deleted]
This is great, thanks :)
If you view the comma and semicolon as separators instead of terminators it works much better. It is also what they really are.
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
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
I'm the author of Learn You Some Erlang, and as pointed out by rvirding in the comments, I've also written a blog entry about the syntax (http://ferd.ca/on-erlang-s-syntax.html). I'll be adding this entry in the book at some point in the future.
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!
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!
Are you sure it isn't the functional paradigm of the language that is frustrating you? That is usually the hurdle for people and not the syntax in my experience - I luckily had quite a bit of experience with Scheme and Haskell so recursion and pattern matching weren't alien to me at all - the idea of taking the car of a list (or head in Erlang) and recursing on the cdr (or tail in Erlang) can be pretty mind boggling for new comers.
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.
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.
It sounds like it's more the syntax is the problem, but if it is indeed that kind of recursion OP is having trouble with, might I recommend The Little Schemer. Amazing short little book with a unique Socratic teaching style that specifically teaches recursing on the cdr of a list.
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.
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.
Yeah, it's syntax for me. It's not functional programming (I do OK with Haskell), it's just this feeling like everything in the syntax looks like a hack. I can't seem to see the underlying consistency (if there is any).
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 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.
Then my suggestion would be to tackle a real problem. It took me a while to know when Erlang was appropriate for what I as trying to tackle. About a year ago, I came across the need to regularly scrape websites from a list (pulled from a mysql DB) and get some very specific information from them (regex worked fine).
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.
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.
Erlang is easier if you know a little Prolog. Perhaps you could download SWI-Prolog[1] and spend a little time doing simple logic programming[2]?
1- http://www.swi-prolog.org/
2- https://sites.google.com/site/prologsite/prolog-problems
1- http://www.swi-prolog.org/
2- https://sites.google.com/site/prologsite/prolog-problems
This isn't good advice; learning Prolog doesn't make learning Erlang any easier at all (not even the syntax, but especially not the semantics). The syntax of Erlang is actually very simple, and mostly an accident of history since Erlang was originally implemented in Prolog[1].
1 - http://stackoverflow.com/questions/3542891/erlang-programmin...
1 - http://stackoverflow.com/questions/3542891/erlang-programmin...
Even though Prolog and Erlang are very different languages that rely on very different paradigms, they do have one thing in common: recursion. Learning Prolog will force you to learn how to think recursively, and will make it easier to then learn Erlang.
That said I'm not sure it's a big win compared to learning Erlang directly.
That said I'm not sure it's a big win compared to learning Erlang directly.
You may be right - logic programming isn't easy and the semantics are different, so it may make things more confusing for a complete beginner (I learned Prolog long ago). For a deeper understanding I would still recommend trying it.
I'd suggest sticking with Erlang a little bit longer. I've only recently learned the language myself so I know what you're talking about. However, for me after a few weeks working with it off and on everything just clicked and now it seems very natural, even enjoyable.
Stick it out, you will get used to it. Comma is AND, semi-colon is OR, and period means END of function definition.
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.
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.
Go [1] is a fairly new language that has lightweight threads and supports message passing through channels. The language is pretty quick to learn, especially if you already know C.
[1] http://golang.org
[1] http://golang.org
Not sure if I am fully answering your question, but I found that some of the web frameworks and demos helped me understand the basics and get working with it much better, particularly http://nitrogenproject.com/demos and http://www.chicagoboss.org/. It helped me relate existing examples to sort of pick up on the syntax a bit, still have a ways to go.
Are you familiar with Erlant/OTP?
Real applications rarely use 'pure' message passing, but wrap everything in OTP's behaviors.
I can only echo what pivo said and tell you to stick it out longer. You can try it out in a suitable development environment which will help out greatly as you wrap your brain around the syntax.
Once you're done with Erlang, you should move on to Haskell. :)
Once you're done with Erlang, you should move on to Haskell. :)
I'm actually going from Haskell to Erlang. I feel OK with Haskell (bar monads), but I wanted to see Erlang's fault-tolerance in particular. I'm a big fan. I just can't seem to get my brain going on it.
I've been going through something very similar myself:
http://stackoverflow.com/questions/5278873/erlang-otp-applic...
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.
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.
The comma, semicolon, period thing is a bit weird in erlang it's a hold over from prolog and makes complete sense in prolog. But the semantic differences of erlang make it a bit more vague.
How about Reia?
http://reia-lang.org/
http://reia-lang.org/
Try posting a problematic piece of code on StackOverflow.
I'm in the same boat on this one. I got an Erlang book, read up everything I could on the -background- of the language (It's older than Java!) Got all mushy over the features and the promise of potential 99.99 uptime or whatever the statistic. This functional programming syntax is difficult, though. I'll probably play with something like Reia (Ruby syntax, Erlang vm) but I realize I'd still have to get a good handle on the Erlang language regardless. I really feel like it was an arbitrary design choice :\
I know. I have the syntax too. It's just one of those things where you have both a bad and a good side. It's about trade offs.
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.
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.
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?