One of the points this article made that I like, and argued for in the other thread was<p>"what matters is fast enough"<p>people love saying X is too slow etc, the only thing that matters is the ability for X to perform up to your requirements, if you need a million concurrent users then yes access will be the wrong tech. but to say X is too slow, you must specify exactly what it is too slow for.
I resent being called "smelly". And I <i>WISH</i> I was 15 again ;)<p>>> "But what none of these detractors seem to understand (except for the script-kiddies) is that the important thing about this demo is the web. CouchDB is part of the web, and serves web applications natively."<p>Yeah ok, CouchDB includes a web server :/ why is that a good thing? Less scaling options when things are bundled together like that.<p>>> "The second set of detractors say realtime applications shouldn't go to disk, because it's slow and a lot of data. To them I say "disk is free"."<p>The only reason a real time messaging system should go to disk, is if persistent logs are required. And in that instance, when you scale, it most certainly is not free.<p>>> "Call me when performance matters."<p>Here's a little story. I built the predecessor to Mibbit using php and mysql. It took a long time. It didn't scale so well. I knew using a db was a stupid idea, but I wanted to see just how stupid. I started using shared memory, semaphores, message queues etc instead. It scaled a bit better, but still lame.<p>In the end I decided to scrap it, and rewrite it from scratch in something I <i>knew</i> would scale. It now does about 2 billion messages a month or something.<p>You should think about scaling from the outset. Having to scrap <i>everything</i> and change language/architecture/etc is kindof a pain. Just because there's some "new" "so hot right now!!!" language/framework/etc out there, it's probably totally the wrong tool for the job.<p>The traffic going back and forth from the browser to the demo CouchDB chat couldn't have been less efficient if it tried - it was sending all 50 recent lines of chat <i>every</i> <i>single</i> <i>time</i>. I don't know if that's easily fixed, probably not. Maybe you'd have to delve into CouchDB code :/<p>I hate this trend of "Less code.. more ease for the developer.." etc. Focus on the user and what they want, and how you can best give it to them. Not what's least lines of code/easiest for you.
1. If you're going to write a "demo app", why not write one that is in the niche that you are targeting. I understand messaging is not it.<p>2. "The second set of detractors say realtime applications shouldn't go to disk, because it's slow and a lot of data. To them I say "disk is free"" I think in many applications it's safe to say that disk space is free, but disk access time certainly isn't, especially if you're syncing transactions to disk on commit.<p>3. "Call me when performance matters." You can write nifty apps with little code in many languages/frameworks. The question is, what happens if the shit hits the fan?<p>4. Hacker News load probably isn't that high. It's certainly not the same as the "slashdot effect".<p>5. "the important thing about this demo is the web ... your applications can be deployed anywhere there's a CouchDB." - I really don't understand this point. The same applies to AMP or Tomcat+Mysql+Java. If it's there you can deploy it. What's P2P about it? I can write Java code that speaks to other Java code on another Tomcat server, and it's not even particularly hard, as there are frameworks for it. I don't like Java, but then again, I don't like JavaScript either.<p>6. "Actually, there isn't much complexity to hide as CouchDB is simple on the inside as well." As a user, I don't care. The point of systems programming is for engineers to sit down and write hi-performance C/C++ code that will then be used by thousands of developers to run billions of transactions for several years. If the engineers spend an extra month to make it 10% faster, then it's worth it, because it will be used by so-many people for a long time.
A lot of thoughtful responses by Chris to reactions to his Toast CouchDB-based chat app.<p>His summary of why he developed Toast: “Toast is a showcase of how simple a real-time chat system can be, when you leverage CouchDB's _changes API.”
<i>the upshot is that my old Mac Mini was able to sustain 4 hours at the top slot on Hacker News without load exceeding 0.3</i><p>I thought everyone had learned to not run anything on Mac Minis (and take backups) after the Magnolia incident: <a href="http://factoryjoe.com/blog/2009/02/16/what-really-happened-at-magnolia-and-lessons-learned/" rel="nofollow">http://factoryjoe.com/blog/2009/02/16/what-really-happened-a...</a>