Hacker News Reader

Comment by doublesCs | Hacker News Reader

> much of the anti-mongo sentiment is around people who used it in 2009-ish.

So? I think this is a very plausible way of measuring how much you should trust something. There had to be a downside to the "move fast and break things" that mongodb subscribes to (i.e., add features now, think about reliability later).

As it turns out, they moved fast and broke their reputation.

View on HN

i agree, there's reputational impact but again it's the trade off that early adopters make and are fully aware of.

When you're the first user of a brand new companies' database, you better bet there will still be kinks they're working through and let's face it you're the guinea pig.

i'm sure mongo is thankful for all these guinea pigs because they helped to define the roadmap and iron out the bugs. however, in the end of the day 2009 version of a product is entirely different than 2020 version. there are endless analogies (facebook, google, etc.) the only difference with an open source technology is users can analyze it under a microscope.

You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?

Depends on what.

You seem to think this is about tech. It's not. It's about company culture, trust, and reputation.

Code can change reasonably fast, in some cases 10 years is enough to replace an entire codebase. But company culture has or can have an expected life time way longer than 10 years. In this case, my heuristic is justified.

Are you not buying iPhones because Apple’s first music player had no wireless and less space than the Nomad?

(For the younger people https://slashdot.org/story/01/10/23/1816257/apple-releases-i...)

How much memory a device has now does not depend on company culture. How reliable we can expect a future feature to be, does.

I think you're making an active effort to misunderstand me.

I’m saying it’s completely illogical to base technical decisions on information that is 10 years old when just like you can see the modern specs of the iPhone and compare to the first iPod, you can also see the modern specs of Mongo, read third party assessments, and even look at the source code to see if it meets your needs.

You have a view of software development so narrow minded to a point it's cartoonish.

You’re right. I’ve only been doing this professionally for 25 years and as a hobbyist for 10 years before that.

I’ve only developed software from everything from 8 bit computers with 128K of RAM, to DEC mainframes to Android tablets....

What do I know?

> You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?

Yes?

The problem was not that MongoDB was young, the problem was that authors of it had no idea about databases when they started their work. They stored data in RAM and get fastest benchmarks, because they didn't worry about persisting the data on disk. They outright lied in their documentation about the guarantees.

It wasn't the being early product part, it was the misrepresenting the truth part that hurt their credibility.

DynamoDB for example is much younger than MongoDB, and doesn't suffer from this.

> They outright lied in their documentation about the guarantees.

> It wasn't the being early product part, it was the misrepresenting the truth part that hurt their credibility.

That's why I replied to the person you're responding to that his view of software development is cartoonish, but I don't think he got it.

> the problem was that authors of it had no idea about databases when they started their work

Speaking of which, have you heard of influxdb? It's going down the exact same route.

yep I heard of it and had similar period of excitement I had with Mongo. Although when they were postponing addition of distributed functionality I lost interest. You can't design a good distributed system as an addon, you need to think about it from day 1.

Reply on news.ycombinator.com