During dev, I had a server live for users to play with. The data structures were in flux, there was zero traditional data input protection. My users were domain experts, no tech background and would type in all sorts of odd inputs as there was no training or documentation on how to use the webapp. But I never once had data corruption issues and never once did the server crash. I was able to run this "test" server with no admin or headaches while I was doing dev.

The reasons are due to a few characteristics of erlang:

1 - you write concrete pattern matching, not abstract object containers. So a controller or model function would spec out a clear data structure that was expected as input. Anything else failed right at the point where the data didn't fit the patterns and guards.

2 - each request is handled by an isolated erlang process that fails gracefully and doesn't effect the rest of the system. So my early testers would get error dumps from the server for bad data inputs but they never corrupted the data or crashed things. I was able to take these error messages from test users to see how they were using the system incorrectly.

3 - Single assignment and functional programming were a big win in terms of writing once, testing once (not writing separate test code), and knowing that that piece of code was solid and I could move on.

The app was very responsive. All requests were ajax and this system felt like the server was running on the same box as the web browser. When we had errors, the erlang error message almost always showed the crash at exactly the point in the code that needed attention.

These characteristics speak to the power of the dev process, not scalability which is what you normally hear about erlang.

===================

string, regex handlers, faster file I/O:

- "re" module replaces "regex"

- faster iteration over large binaries, R13A

- avoid io:get_line using raw access

-----------------------------

metaprogramming/"DSL"

- deep exploring parse_transform

----------------------

frameworks, database, middleware

- couchdb, nitrogen, mochiweb, erlyweb,and now the boss!

- thrift, ejabberd, rabbitMQ,

----------------------------

debug, trace, static code analysis; verify program behavior

- dialyzer, tidier (Sagonas and Avgerinos)

- mcErlang model checker

- quick check application vs. specification

-------------------------

data structures

- destructive / mutable byte arrays (HiPE BIF)

- shared immutable data structure

----------------------

tail recursion

- Ericsson expanding as fast as they can (e.g. "andalso",

-------------

SMP, run queues,

----------

build systems, distribute your app

- rake - faxien, sinan (erlware)

==============

Yah, this could be a long post, take a while to draft too.

Dunno the state of scala, clojure and haskell /GHC docs these days, but to explore the dark corners of erlang dev, you ahve to do a lot of mailing list and google digging.

(and read Cesarini/Thompson book, which is equal to best software books ever, modulo fair number of typo's)

nothing there yet, I've only been erlanging for a month or 2. But: i have been workiing on a better documentation database, you can email for details if interested:

base: genetanigmailcom; insert periods, after positions 4 and 13 and "at" you know where..gene

I can tell you that although merb is a nice framework, I still end up digging through code at times to find bugs that would be much easier to spot if it were in erlang.

Sorry for all the questions, I just think it's an interesting insight to what happens if you pick a language / framework that isn't terribly mainstream.

I started a new webapp two months ago. I ended up using merb again because I already have a merb app in production and could leverage my investment. Merb is obviously not mainstream and even less so now that the project is mostly discontinued in lieu of rails 3.

If I knew now about the length of these projects and my limited funding, I may have stayed with erlang. It was a tough call to let go of it and go with ruby/rails and then have to go to merb due to rails not satisfying my needs to ensure the app only did the things I expected it to do. This is a key issue with rails. Its too complex for some needs. Some apps have a need for simpler frameworks due to security concerns, which was big in my case.

I think it's tough hiring good Ruby/Rails people because they're all busy. And those that aren't, are probably not good to begin with...

(I think the OP mentioned "hasn't worked out as planned" with regards to hiring Rails talent, not erlang)

Then my statement was more directly referring to the Erlang piece of it.

One of the things that crosses my mind every time I start leaning towards one of the more exotic languages is whether or not I'll ever be able to find someone to maintain the software later.

Of course good PHPers are probably busy too.

I have never heard of a company scrapping a business deal because the world ran out of lawyers or accountants. The problem isn't a lack of developers, the problem is a lack of developers at the price the company is willing to pay.

Also, Ruby is way less verbose than Erlang. A lot of pattern matching code seems to fail the "don't repeat yourself" in some ways - you write a lot of the same things, and just one changes.

I don't agree that erlang fails the "don't repeat yourself" test. In fact, I think ruby fails this test miserably in that you have to write so much test coverage. Although Ericsson devs wouldn't agree with this, I found that my code was my tests. I think the difference of opinion has to do with how the apps are used. My apps were end user web apps and my code was solid enough to be its own tests. Ericsson's code is enterprise grade telecom switches and their business model demands test coverage far beyond what most web apps demand. If you tried to write telecom switching code in ruby, your tests line count would be multiples, perhaps an order or magnitude, greater than the line count of the Ericsson erlang tests.

Ruby is class based OO programming, erlang is functional oriented. My erlang webapp line count was very reasonable. I'm not sure I would have fewer lines of ruby for the same app. The syntax sugar that makes ruby so appealing is a drawback as well at times: the code can be ambiguous with the only way to be certain of what it does being to write tests. Erlang syntax takes getting used to, it certainly doesn't have the immediate appeal as ruby. But it makes up for this in that once you are comfortable reading erlang, you can simply read the code and be certain of what it does and that it does it correctly.

    skip_past_separator([]) ->    
	[];
    skip_past_separator([$; | Rest]) ->
	Rest;
    skip_past_separator([$, | Rest]) ->
	Rest;
    skip_past_separator([_ | Rest]) ->
	skip_past_separator(Rest).

Different strokes I guess, but in my experience I found myself repeating code a lot less in Erlang due to the functional nature of the language and because it made certain bits of repetition in the code more obvious due to the "shape" of code in my editor.

In terms of refactoring... I've seen code like that scattered through Erlang often enough to have a slight dislike for it (it is not a Major Problem with the language, and pattern matching is elegant).

And to some degree - it is a function of the language:

     foobar(a, b, c=1) ...

     foobar(A, B) -> ...;
     foobar(A, B, C) -> ....

I don't dislike Erlang - quite the contrary - I first encountered it professionally in 2003 and have dabbled now and then with it. I just think it can be a bit "uneven" - which makes me think it will likely never catch on as a very widespread general language.

And I don't believe in "the right tool for the job" - most people are going to know a few languages (at best) and stick with them, because for most things, it's cheaper in terms of overall effort to do something with a language you know than doing it with something you don't and have to learn (also likely not doing as good a job, because you're new to it), even if the result isn't perfect. So languages that are niche only, in my mind, are probably going to be less popular than they could have been if they were more general purpose.

The thing I dislike most about erlang, besides the lack of a good macro system, is that the repl is full of annoying special cases, so you have to actually stick your code in a file with a proper module name and compile it in order to test stuff :(

http://www.erlang.org/doc/man/lists.html

http://news.ycombinator.com/user?id=RKlophaus

I met the guy in D.C. and he lives and breathes Erlang.

Thanks!

http://www.evanmiller.org/nginx-modules-guide.html

It does make some big claims, but I've been looking for a reason to mess with Erlang for a while and this seems pretty neat.

I think I'll wait awhile on this one...

*Note: for this to work, you will need a large sandbox. If it is too small, your car will be fine, but just try explaining what happened to the sandbox to your kid.

What makes you so sure that I'm wrong about the latter?

My other open window is running emacs; it's where I've been writing Python code for App Engine for the past few weeks. If that doesn't qualify me as a developer, please describe the requirements, as I've been writing code since the late 70s.

Of course the previous poster is making a generalization. If you're in the minority of developers using IE, good for you.

Developers are usually smarter than to use a browser with appalling performance and a plethora of bugs (that never get fixed) when much better choices are just a few clicks away.

This is probably a troll, but i'm hitting reply anyway...

So the problem is that I'm "not smart" (enough). Okay - so I'll ask a dumb question. Are those the only relevant criteria for choosing a browser? Or, are they merely always dominant?

> This is probably a troll, but i'm hitting reply anyway...

Not at all. I'm open to self-improvement.

Frankly, I can't begin to fathom why you would willing use IE when the Chrome plugin, Firefox, Chrome itself, Safari, and various smaller webkit browsers are available to you.

I've never really seen the advantage of using Emacs unless you're a lisp hacker. Seriously. Also the keyboard shortcuts on Emacs are rather similar to a lot of the universal shortcuts on OS X, which you don't appear to use either.

So either potential mutual benefit you could derive from using Emacs is being left for dead.

Also, you're a developer and you're using the very browser that's holding back our ability to build universal and standards compliant web sites/apps? Seriously?

You're just a part of the problem, regardless of vocation.

As for editing, I use Textmate/Gedit for code, vi for unixy stuff.

>> Developers are usually smarter than to use a browser with appalling performance and a plethora of bugs (that never get fixed) when much better choices are just a few clicks away.

>So the problem is that I'm "not smart" (enough). Okay - so I'll ask a dumb question. Are those the only relevant criteria for choosing a browser? Or, are they merely always dominant?

rubs face Okay.

You're knowingly using a browser that is buggy, slow, insecure, and is holding back the entirety of the web app dev community.

Relevant criteria? That's all there is to the matter! Unless you're being paid to use that abhorrent bucket of bile I can't fathom a legitimate reason to utilize it as a developer. Standards compliance, stability, performance, security...yeah...uh, what else factors into your choice of browsers, the phase of the bloody moon?

YC haet you. :P

>>>All other web frameworks will break down and cry if you ask them to process more than a few dozen simultaneous requests on a single machine.<<<<

Isn't this what facebook Tornado, Orbited and all the other servers using select()/epoll() solves?

I also find it somewhat funny that it includes an ActiveRecord port - an object-relational mapper in a functional language to talk to a non-relational backend (tokyo tyrant).

Chicago Boss is fully asynchronous, using one single process to handle hundreds or thousands of simultaneous requests, and thus it solves the classic c10k problem. All other web frameworks will break down and cry if you ask them to process more than a few dozen simultaneous requests on a single machine. Chicago Boss is built with Erlang, the same platform used by banks and telecoms to achieve unprecendented scalability and (no exaggeration) 99.9999999% reliability.

Oh my

A typical single Ericsson AXD 301 switch had a target of 5 nines of reliability without network redundancy, which is 5mins/year, including planned outages. see http://www.erlang.se/publications/Ulf_Wiger.pdf

One of the advantages of these switches was that they could manage 95% throughput at 150% load (Throughput then drops linearly to 40% at 1000% sustained load), which is also extremely useful, although not mentioned often.

Of course, this is the problem you get once you've solved the hard problems already, which is how to get that many visitors in the first place. At this point you have the money to buy a bunch of servers, typically, so this is aimed at people who are really great at getting incredible numbers of hits, but really poor at monetizing them.

Premature optimization is the root of all evil and all that, but going at the other extreme is equally not the smartest thing you can do.

An application like 37signals Basecamp can grow organically over time as the application is maturing and more and more users discover it and start paying for it. But if your project's success depends on the number of users you have (e.g. a social app), it makes sense to think about scaling and reliability a little beforehand.

Remember Twitter? It's still a mystery to me how this app survived having so many outages. Maybe they where lucky, maybe the social aspects where worth it for its users, but that doesn't mean your application will survive if facing such problems.

http://www.youtube.com/watch?v=1yH_j8-VVLo

Looks interesting, though.

All other web frameworks will break down and cry if you ask them to process more than a few dozen simultaneous requests on a single machine.

If you believe every other web framework will get crushed with a few dozen simultaneous requests, you will be absolutely sure this is the solution you have been waiting for.

I am curious to try Erlang out, but I know exactly how many dozen requests my current tools can handle. And it's a lot more than a couple.

I dunno. Vagueries. :)

By writing something in Erlang does not make your program automagically perform well (and this applies to CouchDB too).

Ignorance and/or disenguity(sp?) pisses me off. I'll read more but I'm getting the impression that people behind BOSS are one or more of inexperienced, clueless, full of them selves and thus not worth my time.

Although, I just downmodded you because it seems like you've got a tough time being civil.