Comment by Perceptes | Hacker News Reader

Comment by Perceptes | Hacker News Reader

I really appreciate the deep introspection in this post. We can all learn a lot from it. I'm one of the (possible minority) of HN users that doesn't care about startups and business, so for me the takeaway was about how choosing quality and correctness over speed works out in the real world. It seems that you really can't take the idealist approach to quality that RethinkDB took. The world just isn't willing to wait, and it's not willing to take the time to understand a system and to see how clearly it distinguishes itself from the alternatives. Our decisions are driven by speed. Our culture is "always be shipping." But part of the result of this is that all our software is riddled with bugs and usability issues. Even the most basic functionality of our computers fail all the time, all the way down the stack. It's depressing that a really solid, honest attempt to produce extremely high quality software like RethinkDB can't survive in part because of these things.

> The world just isn't willing to wait, and it's not willing to take the time to understand a system and to see how clearly it distinguishes itself from the alternatives.

This world is always willing to wait, it was the RethinkDB team and/or their investors who weren't. The world will wait for you in eternity; it's just not willing to provide you with capital during the wait.

Your statement makes sense if there were a dozen competitors in the database space. With hundreds of competitors, actually evaluating them all becomes more expensive than just choosing eg. a managed SQL solution and then switching provider if it doesn't live up to its promises.

That's so much more flexible from a business perspective than evaluating a hundred different open source database systems, settling on one, and then having to rewrite your database code when the database you've chosen ceases development, and you're left as the maintainer of it.

I was a huge advocate of RethinkDB, absolutely love what Slava and the team were able to accomplish, but I am having a really hard time digesting that "Correctness", "Simplicity of the interface" and "Consistency" were the issue here. Example: Realm.

I can only imagine what the team at Realm is thinking after going through comments and the post-mortem. Realm was an open-source mobile first database for the past 3 years. It's free. Its the most correct, consistent, and simple mobile database that is running on millions of devices[1] (Yup fine, kind of my opinion but trust me mobile community will back this up). They ship FAST, they ship real USECASES. They just recently entered the cloud space with their Mobile Database Platform, and they are even experimenting with new things like a version built for Node.js.

I'm honestly not trying to make a specific point, but asking more questions... Is mobile different? Is it easier? Are mobile developers more willing to try new technology? Are they more willing to pay for technology? (Realm is free, haven't paid them a penny, so not sure about this one...)

My main point I guess is that it's not a terrible market, Realm made it work with VERY similar ideals and goals. So what else is going on here?

[1] https://realm.io/news/jp-simard-realm-core-database-engine/

I'm not familiar with Realm, but after a brief glance at their site:

Yes, mobile in this context is very different. Or rather, local is very different. Building a database that resides on a local device and is primarily accessed by a single user is an entirely different class of problem than one that is on a server. Usually most of the hard problems in building a database system involves dealing with multiple people accessing or modifying data at the same time. When you have a single user, that problem either disappears or is massively reduced.

As you said, Realm does appear to have a server offering now, but from the sounds of it, it hasn't really been proven yet, so I don't think it's as easy as saying they've succeeded where Rethink failed.

Absolutely, in no way am I saying their cloud offering is successful. What I am saying is they have shown you can be successful with the very same ideals and goals that the RethinkDB team had, with a very similar developer-minded audience. The biggest factor here is obviously the platforms their database runs on - Mobile (or local as you put it nicely) vs cloud.

> Is mobile different? Is it easier?

It's easier to get adoption for mobile, I'd think.

Database component designed for use by mobile applications: something you base an app around

Database server: something you base your business around

I don't actually think it is easier to get adoption. The major mobile platforms have SQLite built-in (under the hood in the case of Core Data). I think that's actually a strong barrier to overcome.

Furthermore, mobile is becoming in-demand or even core in both consumer and enterprise. For enterprise especially, though, you have to think of it as mobile + sync, not on-device only.

Turns out sync is the really hard part when you want to build something that's robust in the face of poor network connectivity.

It's probably too early to say that Realm made it work.

They've raised a roughly similar amount of VC money as RethinkDB did. Their last raise was a few years ago, before Parse's shutdown, so I suspect that investors are more antsy about this space today.

The fact that Realm recently entered the cloud space sounds similar to RethinkDB's trajectory too... Of course I hope Realm makes it, it's a great product. But I'm worried that they're trapped in the VC-funded model like RethinkDB was.

It's in the Worse is Better essay. Strange enough, the essay series the author drew on advised the opposite strategy because it wins in the market. Here's a simpler one from someone who developed a product in high-assurance security then worked to turn Microsoft security around:

https://blogs.microsoft.com/microsoftsecure/2007/08/23/the-e...

He details why they put marketing and shipping first with constant improvements on correctness or security. On top of this, I advise just embedding the benefits into the product & designing it for easy change so components can be replaced once big revenue comes in. As development pace slows, QA pace can increase on components stabilizing.

Yes, worse is better.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Reply on news.ycombinator.com