The most basic cause for bad technical decisions are wrong assumptions about technology.

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'd be interested in some numbers. Is it "a few"? "some"? Give us some vague quantifiers here!

Before I roll-out apps to the folks who will really torture them in production-like servers, I play with about 100 simultaneous connections.

100 is really only a few dozen :)

but it's close to 10 dozen...which is almost a dozen dozen...

I dunno. Vagueries. :)

Gross.

But that is on a notebook. The numbers the server folks put them through are much higher.

Usually it's not the web framework itself that is unable to process the requests, but the web application in which one http request ends up in a few database requests, and the database is the real bottleneck.

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

Will his default data store choice (Tokyo Tyrant) solve this? It could be a bit too early to answer that.

Short answer is no. Most of the "slow" queries that happen in databases are usually complicated select/join/update statements -- the same can happen for key/value databases. Even with TC, you're still programmatically writing the code to do the query and if you write slow code, your query will still be slow. The sweet sweet technology isn't going to magically solve anyone's problems.

Chuckle?

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.

If you can't get more than a couple dozen req/sec out of other things, you probably won't manage it with this, either.