Not sure about the wiki - if it doesn't fully implement everything MediaWiki does, it may be too early to compare performance (80/20 thing). CouchDB on the other hand is very promising, as a whole new DB concept.
CouchDB sounds interesting, but the wiki thing is the opposite of a "killer app" -- I'm sure it's a nice demo, but MediaWiki is a seven year old app. As a PR exercise, it just serves to enhance Erlang's unfortunate reputation as a great language for writing prematurely optimized code that ships late. If you want some positive PR, rebuild Twitter, and do it before 2010. Better yet, build something new, or something profitable, or both.
They say this thing is "faster" than the current Wikipedia, but they don't really say how much faster. Benchmarks are deceptive. Where's the cost-benefit analysis -- you're asking me to have one of the world's top Erlang hackers rearchitect an app in a language that only a handful of expensive, talented people can understand, and for what? Will the Wikimedia foundation save $10k per year? $100k?
And, when Wikipedia's competitors start adding features, will the foundation discover that the cost of modifying their super-optimium Erlang app completely outweighs the savings in server hardware? Wikimedia isn't in the telecom industry: They don't have a monopoly, and their specs might have to change more often than once every decade or two.
You are obviously focusing on the presentation-layer (mediawiki) and completely ignoring the data store that everyone else is quite psyched about.
Here is what scalaris provides: distributed, fault-tolerant, replicated key-value store (a la Dynamo/SimpleDB.) This layer can be smeared out across hundreds or even thousands of nodes, it can provide data consistency across the replicas (via Paxos, something that SimpleDB/Dynamo cannot provide and pass back to the application layer for reconciliation) and it can do this rather quickly.
That is a rather powerful component to make readily available to any Erlang app. If you can't think of ten or twenty possible applications of this then you are not trying hard enough.
Comments
Some interesting stuff there.
Not sure about the wiki - if it doesn't fully implement everything MediaWiki does, it may be too early to compare performance (80/20 thing). CouchDB on the other hand is very promising, as a whole new DB concept.
CouchDB sounds interesting, but the wiki thing is the opposite of a "killer app" -- I'm sure it's a nice demo, but MediaWiki is a seven year old app. As a PR exercise, it just serves to enhance Erlang's unfortunate reputation as a great language for writing prematurely optimized code that ships late. If you want some positive PR, rebuild Twitter, and do it before 2010. Better yet, build something new, or something profitable, or both.
They say this thing is "faster" than the current Wikipedia, but they don't really say how much faster. Benchmarks are deceptive. Where's the cost-benefit analysis -- you're asking me to have one of the world's top Erlang hackers rearchitect an app in a language that only a handful of expensive, talented people can understand, and for what? Will the Wikimedia foundation save $10k per year? $100k?
And, when Wikipedia's competitors start adding features, will the foundation discover that the cost of modifying their super-optimium Erlang app completely outweighs the savings in server hardware? Wikimedia isn't in the telecom industry: They don't have a monopoly, and their specs might have to change more often than once every decade or two.
You are obviously focusing on the presentation-layer (mediawiki) and completely ignoring the data store that everyone else is quite psyched about.
Here is what scalaris provides: distributed, fault-tolerant, replicated key-value store (a la Dynamo/SimpleDB.) This layer can be smeared out across hundreds or even thousands of nodes, it can provide data consistency across the replicas (via Paxos, something that SimpleDB/Dynamo cannot provide and pass back to the application layer for reconciliation) and it can do this rather quickly.
That is a rather powerful component to make readily available to any Erlang app. If you can't think of ten or twenty possible applications of this then you are not trying hard enough.
"If you want some positive PR, rebuild Twitter, and do it before 2010"
Twitter is already done: http://twoorl.com/
Without all the users of course.
They didn't implement a Wiki. They implemented a distributed storage backend in which the Wiki pages are stored.