4 ms·

I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (betwe

I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, that software is often shaky in its infancy but almost always improves over time.

throwawaygh 6y ago
I had to rip out a comletely schemaless mongodb and replace it with a sql DB. The data was completely relational, and developing without a schema was a pita. I asked why mongodb was used in the first place. As far as I could tell, the answer was one resume driven dev. If a document store made sense for our data then we would’ve made mongodb work. It was less “we got burned” and more “why were we using mongo in the first place?”
- daneel_w 6y ago
  This was a bit of a hidden point with my comment. A poor choice of tool for the job is a completely different problem than the tool being poor.
derivagral 6y ago
I don't think this is limited to devs or databases. You see it sometimes in Firefox/Chrome threads along the lines of "firefox sucks", "when did you last use it?", "4 years ago". Mongo in particular had marketing plays that were quite deceitful; that particular flavor of distate can run deeper than some tech issues. disclaimer: I use mongo in my day to day as a primary DB store.
AdrianB1 6y ago
If you have a problem with product A and you have 10 other options, find product B is good enough and start working with it, there is no need to go back to A from time to time to see if it was improved. And watching all the 10 products like a horse race and move to the best of the hour is not reality.
Volundr 6y ago
Here's the thing, it's not just that early Mongo had issues, sure whatever that's life. But they argued that things like silently dropping data if your database gets too large were acceptable because it's documented (and this is just one such issue). The sole, number one requirement I have for my database is that the data I put in is still there when I go to get it back. Failing that and pretending it's not an issue is more than "being shaky", it's a violation of the trust I put in my data-store. It's great they've fixed those issues now, but that cavalier attitude towards data the integrity of my data is what makes me hesitant to use it in future, not the fact that a bug involving data-loss existed. None of this is to say I'd never use it, but it'd be far harder for me to trust it again vs postgres, couch, rethink, cassandra, or any number of other data-stores that took data integrity seriously from the start.
deleted 6y ago
[deleted]
sgift 6y ago
The problem with MongoDB is not that it was shaky in its infancy. It is that the developers made it very clear from the start that they don't care. Speed is everything, everything else is secondary. This changed a bit over time, but the latest Jepsen report (http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6) is still a mess and by now I'm pretty sure that is less "shaky in its infancy" and more a deep seated design problem that will never be fixed.
VHRanger 6y ago
Apple is is using AMD GPUs for basically that reason though
tjalfi 6y ago
Life is too short to reevaluate every technology I've had a bad experience with. You only get one chance to make a first impression - I'll probably stick with it unless I get an excellent reason to change my mind. How often do you reevaluate technologies that you've had a bad experience with?
- daneel_w 6y ago
  How often I re-evaluate applications, you mean? I would say it happens somewhat regularly; if there's something I miss with one I switched from, or if I hear or read something good about an application I stopped using.
  - contrast 6y ago
    I guess the more interesting questions are how often you re-implement discarded technologies back in to your core stack after they’ve let you down, and how much time you spend re-evaluating your core tech but don’t find enough improvements to incur the switching costs. For something as fundamental as the database, most developers (and people who rely on them) would probably hope for “rarely” and “not much”. What are the benefits you see from taking a different approach?
  - tjalfi 6y ago
    I was thinking of platforms or programming languages, e.g. the JVM, the .NET Core runtime, Go, Python, etc. I consider MongoDB a platform. I don't change applications that often. I'll try a new application when I have a new problem but my current applications are good enough for now.

throwawaygh 6y ago

I had to rip out a comletely schemaless mongodb and replace it with a sql DB. The data was completely relational, and developing without a schema was a pita. I asked why mongodb was used in the first place. As far as I could tell, the answer was one resume driven dev. If a document store made sense for our data then we would’ve made mongodb work. It was less “we got burned” and more “why were we using mongo in the first place?”

daneel_w 6y ago
This was a bit of a hidden point with my comment. A poor choice of tool for the job is a completely different problem than the tool being poor.

derivagral 6y ago

I don't think this is limited to devs or databases. You see it sometimes in Firefox/Chrome threads along the lines of "firefox sucks", "when did you last use it?", "4 years ago". Mongo in particular had marketing plays that were quite deceitful; that particular flavor of distate can run deeper than some tech issues. disclaimer: I use mongo in my day to day as a primary DB store.

AdrianB1 6y ago

If you have a problem with product A and you have 10 other options, find product B is good enough and start working with it, there is no need to go back to A from time to time to see if it was improved. And watching all the 10 products like a horse race and move to the best of the hour is not reality.

Volundr 6y ago

Here's the thing, it's not just that early Mongo had issues, sure whatever that's life. But they argued that things like silently dropping data if your database gets too large were acceptable because it's documented (and this is just one such issue). The sole, number one requirement I have for my database is that the data I put in is still there when I go to get it back. Failing that and pretending it's not an issue is more than "being shaky", it's a violation of the trust I put in my data-store. It's great they've fixed those issues now, but that cavalier attitude towards data the integrity of my data is what makes me hesitant to use it in future, not the fact that a bug involving data-loss existed. None of this is to say I'd never use it, but it'd be far harder for me to trust it again vs postgres, couch, rethink, cassandra, or any number of other data-stores that took data integrity seriously from the start.

deleted 6y ago

[deleted]

sgift 6y ago

The problem with MongoDB is not that it was shaky in its infancy. It is that the developers made it very clear from the start that they don't care. Speed is everything, everything else is secondary. This changed a bit over time, but the latest Jepsen report (http://jepsen.io/analyses/mongodb-4.2.6 http://jepsen.io/analyses/mongodb-4.2.6) is still a mess and by now I'm pretty sure that is less "shaky in its infancy" and more a deep seated design problem that will never be fixed.

VHRanger 6y ago

Apple is is using AMD GPUs for basically that reason though

tjalfi 6y ago

Life is too short to reevaluate every technology I've had a bad experience with. You only get one chance to make a first impression - I'll probably stick with it unless I get an excellent reason to change my mind. How often do you reevaluate technologies that you've had a bad experience with?

daneel_w 6y ago
How often I re-evaluate applications, you mean? I would say it happens somewhat regularly; if there's something I miss with one I switched from, or if I hear or read something good about an application I stopped using.
- contrast 6y ago
  I guess the more interesting questions are how often you re-implement discarded technologies back in to your core stack after they’ve let you down, and how much time you spend re-evaluating your core tech but don’t find enough improvements to incur the switching costs. For something as fundamental as the database, most developers (and people who rely on them) would probably hope for “rarely” and “not much”. What are the benefits you see from taking a different approach?
- tjalfi 6y ago
  I was thinking of platforms or programming languages, e.g. the JVM, the .NET Core runtime, Go, Python, etc. I consider MongoDB a platform. I don't change applications that often. I'll try a new application when I have a new problem but my current applications are good enough for now.