Build Your Next Web Application with Erlang
weblog.miceda.org
weblog.miceda.org
First off, I found info saying that yaws wouldn't work because it has hard coded timeouts. Then I found erlycomet. But none of the samples worked.
Moving on, I found nitrogen. This was the one true diamond in the rough. It works, it has real documentation, and it's pretty well designed, at least according to my one day experience in erlang land.
Side note here that both these projects use mochiweb, which is like the new hotness apparently. But documentation for mochiweb? Ha, forget about it.
Once I got the basic page up, I decided to go with couchDB for a backend. You'd think that with couchdb also being written in erlang, there'd be some good client libraries, but the situation is pretty much a clusterfuck. erlang_couchdb was the best I found, except none of the examples in the README actually worked. And there's not much in the way of documentation. The main problems stemmed from there being different ideas of what should represent a document. Some functions used a pattern like {json, { wawawa }} others used a pattern more like [{json, [wawawa]}] and so on and so forth. The document get and put operations used different forms! put(get) crashed!
Primary conclusions I drew:
1. erlang web development is just too immature yet. Half the libraries you need are just random code dumps in github or google code. There's piles and piles of blogs and articles like this that tell you all the choices, but don't do much to explain why you'd want one or the other. Piecing it all together is very frustrating.
2. erlang as a language has the lethal combination of dynamic pattern matching. Pattern matching in a static language like ocaml? Awesome. Dynamic types in language like python/lua? Qualified awesome. Those features together? MOST ANNOYING THING EVER. Everytime my app (and by my app, I mean the example code I was running) crashed with a "oops, I didn't find the right pattern" error, it was unfuckingpossible to determine who/what/why was at fault.
It's not the syntax or the functionalness or the strangeness of erlang that killed me. It was dynamic pattern matching and the difficulty of figuring out what went wrong. I'm avoiding it like the plague from now on.
mochiweb_http:start(Options)
Socket = Req:get(socket),
inet:setopts(Socket, [{active, once}]),
% Send message to comet handler here
receive
{tcp_closed, Socket} -> ok;
{error, timeout} -> send_timeout(Req);
{msg, Data} -> send_data(Req, Data)
end.
your 2 complaints are valid, for web development erlang certainly doesnt have nicely documented easy to use libraries, but they are coming along.
and as for the "dynamic" pattern matching, I think this is more down to experience, erlangs pattern matching is very simplistic and although when something doesnt match when you expect it to, its incredibly annoying to find out why (by incredibly annoying you just print it out before it attempts the match, then look to see why it doesnt match)
but this happens very rarely, at least in my experience.
There's 2 books in print, one Manning MEAP, (and 2 in the pipeline by Gerakines and Cant that I'm confident will be solid.) And if you ask on the list or stackoverflow, you'll get a patient, complete answer most of the time. Folks from Ericsson's core development team, ETC (erl training/consulting the company), and people like Robert Virding participate actively.
tip: the "Search this Group" box on google groups appears ot have had a heavy object dropped on its head. Use a regular goog search with "group:erlang-programming"
It is way too immature at the moment, no doubt.