4 ms·

Buzz + Buzz + Buzz = Boss Looks interesting, though.

by middus 17y ago

tortilla 17y ago
A little bombastic, but I got a chuckle out of this line: 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.
- njharman 17y ago
  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.
- agazso 17y ago
  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).
  - subbu 17y ago
    Will his default data store choice (Tokyo Tyrant) solve this? It could be a bit too early to answer that.
    - catch23 17y ago
      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.
- rbanffy 17y ago
  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.
  - Periodic 17y ago
    I'd be interested in some numbers. Is it "a few"? "some"? Give us some vague quantifiers here!
    - rbanffy 17y ago
      Before I roll-out apps to the folks who will really torture them in production-like servers, I play with about 100 simultaneous connections.
      - count 17y ago
        100 is really only a few dozen :)
        cschep 17y ago
        but it's close to 10 dozen...which is almost a dozen dozen... I dunno. Vagueries. :)
        LogicHoleFlaw 17y ago
        Gross.
        rbanffy 17y ago
        But that is on a notebook. The numbers the server folks put them through are much higher.
- ubernostrum 17y ago
  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.
chasingsparks 17y ago
I strongly dislike developing web front-ends in Erlang. However, if you are interested in doing so, please also see the comparably stable http://erlyweb.org/ http://erlyweb.org/ by Yariv, who is a visible figure in Erlang web development.

Buzz + Buzz + Buzz = Boss Looks interesting, though.

by middus 17y ago

Buzz + Buzz + Buzz = Boss Looks interesting, though.

A little bombastic, but I got a chuckle out of this line: 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.

njharman 17y ago
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.
agazso 17y ago
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).
- subbu 17y ago
  Will his default data store choice (Tokyo Tyrant) solve this? It could be a bit too early to answer that.
  - catch23 17y ago
    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.
rbanffy 17y ago
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.
- Periodic 17y ago
  I'd be interested in some numbers. Is it "a few"? "some"? Give us some vague quantifiers here!
  - rbanffy 17y ago
    Before I roll-out apps to the folks who will really torture them in production-like servers, I play with about 100 simultaneous connections.
    - count 17y ago
      100 is really only a few dozen :)
      - cschep 17y ago
        but it's close to 10 dozen...which is almost a dozen dozen... I dunno. Vagueries. :)
        LogicHoleFlaw 17y ago
        Gross.
      - rbanffy 17y ago
        But that is on a notebook. The numbers the server folks put them through are much higher.
ubernostrum 17y ago
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.

chasingsparks 17y ago

I strongly dislike developing web front-ends in Erlang. However, if you are interested in doing so, please also see the comparably stable http://erlyweb.org/ http://erlyweb.org/ by Yariv, who is a visible figure in Erlang web development.