4 ms·

I do believe that Erlang is the right tool for the job when you're building a distributed database, especially for the distribution part. For a company like Bas

I do believe that Erlang is the right tool for the job when you're building a distributed database, especially for the distribution part. For a company like Basho it's understandably a good investment to take expert distributed systems/database engineers and let them take their time learning Erlang. If, however, you, like most of us, are not building a distributed database, think carefully before you choose Erlang, especially if you're in a startup. Most startups don't have a distributed database as their core technology, and for many startups, it's important that developers can push production code from day one.

derefr 13y ago
I think the important question for HN, here, is: what "app ideas" map, in the end, to "having a distributed database as core technology"? If you're building the next Facebook, is that, fundamentally, a distributed database? If you're building an MMO, is that, fundamentally, a distributed database? If you're building a payments platform, is that, fundamentally, a distributed database? And so forth.
- derefr 13y ago
  Jeez, and here I was hoping someone would have an answer ready to hand. Instead, I get 13 upvotes (at time of this writing) from people who are presumably wondering the same thing. I guess this might be something worth doing a bit of research and writing an article about. :)
- oneweekwonder 13y ago
  What distributed application can not be "philosofed" into essentially being a distributed database, and I feel like I'm just repeating your question. With that in mind, I believe it boils down to where is the logic located, with the data, or not. Because a lot of "databases" are just used as a datastore. So let me try to create some scenarios: 1. To push out a product(Startup/Prototype/POC): Develop in the technology you know, and let the stake holders know you are acquiring Technical Debt. After startup/prototype product is a success. Explain to stake holders why you need to move to a better technology stack that supports distributed systems "better". 2. If you have a design or product, develop directly in a distributed technology stack. It boils down to use the correct tool for the correct job, but you will mostly only know if you used the correct tool later in the development of the product.

derefr 13y ago

I think the important question for HN, here, is: what "app ideas" map, in the end, to "having a distributed database as core technology"? If you're building the next Facebook, is that, fundamentally, a distributed database? If you're building an MMO, is that, fundamentally, a distributed database? If you're building a payments platform, is that, fundamentally, a distributed database? And so forth.

derefr 13y ago
Jeez, and here I was hoping someone would have an answer ready to hand. Instead, I get 13 upvotes (at time of this writing) from people who are presumably wondering the same thing. I guess this might be something worth doing a bit of research and writing an article about. :)
oneweekwonder 13y ago
What distributed application can not be "philosofed" into essentially being a distributed database, and I feel like I'm just repeating your question. With that in mind, I believe it boils down to where is the logic located, with the data, or not. Because a lot of "databases" are just used as a datastore. So let me try to create some scenarios: 1. To push out a product(Startup/Prototype/POC): Develop in the technology you know, and let the stake holders know you are acquiring Technical Debt. After startup/prototype product is a success. Explain to stake holders why you need to move to a better technology stack that supports distributed systems "better". 2. If you have a design or product, develop directly in a distributed technology stack. It boils down to use the correct tool for the correct job, but you will mostly only know if you used the correct tool later in the development of the product.