RethinkDB Postmortem • Hacker News Board

Re: RethinkDB Postmortem

#201

Post by geodel » Wed, Jan 18, 2017, 3:08 PM UTC

yummyfajitas wrote: post #142

lelandbatey wrote: post #68

Earlier quoted context omitted.

I'm going to fundamentally disagree with at least the target of Go. Go introduced a series of concurrency primitives with syntax that's made writing and reasoning about concurrent code a joy, something that's not the case in Java/C++/C/Python (maybe up till the late 3.X in the case of Python), and it did that with a language paradigm (interface driven) that's vastly different from Python's mixture of OOP and duck-typ…

Go didn't "introduce" CSP or actor like primitives. Scala had actors in 2006, I think Clojure has for a similar amount of time as well. There have been libraries for it in Java and C++ also since the early 2000's and probably earlier. Plenty of other people would say "I wonder how far along the industry would be if you people would actually learn how to manage your memory and write C". I don't see the industry gravit…

> Rust actually requires the developer to learn new concepts (borrow checker)

Well they do not want GC for their language hence borrow checker while Go already has an excellent GC.

As opposed to learning new things we need useful new things which couldn't be done before fancy new language.

Re: RethinkDB Postmortem

#202

Post by EdiX » Wed, Jan 18, 2017, 3:20 PM UTC

yummyfajitas wrote: post #56

I do find it truly sad how anti-intellectualism is pervading our industry and causing good products to die. Nowadays, a significant number of the hottest new technologies offer literally nothing of value beyond "low learning curve". It's my current belief that tech culture has lost nearly everything that once made us great. Think about some examples. MongoDB is nothing but the object databases of the 80's, rebranded.…

    Go's entire selling point is "faster than python, no need to learn anything new". In terms of language features it's again living in the 80's - Java got generics in 2004 and Java was way behind the times. In terms of speed it's worse than Java and Rust, maybe comparable to Haskell.

This is not true, go is generally slightly faster than java (while using less memory_ and slightly slower than rust. The garbage collector is slower than java's default collector but has better latency but java's gc can be tuned and go gives you better tools to bypass gc partially or entirelly.

Re: RethinkDB Postmortem

#203

Post by notacoward » Wed, Jan 18, 2017, 3:34 PM UTC

Here's the part that resonated with me.

> we fought the losing battle of educating the market.

I've been at ten startups. At least half of them chose that battle, and that would be the less successful half. Sales cycles are fragile things. Anything that slows them down can be fatal. Clearly you need to explain how your offering is unique and special, but if you have to pause to explain basic concepts before they get it then you've probably lost their attention and their business.

The VP of marketing at one of my previous companies was generally an idiot and one of the chief drivers of that company's failure, but he introduced me to the concept of market vs. technical risk. A product can be easy to market but a challenge to build, or it can be the other way around. You can build a strategy around either. If it's hard in both ways, you're in trouble. Frankly, it sounds a bit like that's the trap RethinkDB fell into. They were doing things that were technically hard and hard to explain to users. That's how you get three years behind.

It's a sorry situation, but kudos to the RethinkDB folks for trying to do the right thing, mostly succeeding from an engineering perspective, and writing honestly about how that played out in a market of people who aren't equipped to appreciate it.

Re: RethinkDB Postmortem

#204

Post by bryanlarsen » Wed, Jan 18, 2017, 3:34 PM UTC

While I think @coffeemug's analysis is good, I think it glosses over the core issue: money.

rethinkdb's core issue IMO was that they took VC money, which did two things:

- mandated that success had to be a home run

- gave them a fixed runway

Sure, rethinkdb made some mistakes, but I think those were successfully corrected. The problem is that those corrections were too late and they ran out of runway, and the success looked more like a triple than a home run so they couldn't go back to VC's for more.

Of course, not taking VC would have slowed things down even more, but that's fine. The primary attribute many look for when choosing a database is trust, and trust takes years to earn.

mongodb vs rethinkdb is very comparable to mysql vs postgresql, and I think the final results will turn out very similar. mysql did very well and was the leader for a long time, but today postgresql is the clear favorite.

Re: RethinkDB Postmortem

#205

Post by sanderjd » Wed, Jan 18, 2017, 3:37 PM UTC

raverbashing wrote: post #157

niftich wrote: post #151

Earlier quoted context omitted.

Schema-less data always sounds good in the beginning until you actually try to use that data. Then you end up encoding all the validation and data munging logic into whatever process reads from it. An internally-schema'd database just recognizes that this is absurd and lets you put the bottom three layers of validation logic inside the database, where you only have to do it once.

> Then you end up encoding all the validation and data munging logic into whatever process reads from it. Do you think that doesn't happen in regular DBs or that schemas don't evolve? Love for static typing is basically Stockholm's syndrome Your system will eventually end up with a fixed schema, but until you get to that place you don't need to "stop the world" to change it. "But Postgresql can add columns without do…

> Love for static typing is basically Stockholm's syndrome

Funny, that's sort of how I feel about my (long) time "loving" dynamic typing. Now I find it is such a relief to validate data once on the way in and completely trust it to be what it says it is thereafter. I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere.

YMMV I suppose.

Re: RethinkDB Postmortem

#206

Post by jldork » Wed, Jan 18, 2017, 3:37 PM UTC

Yeah, my perspective is that Mongo just positioned themselves well in their marketing. They became a default option as part of the MEAN stack.

I wonder if Rethink somehow piggybacked on React or Angular in the same way...

Re: RethinkDB Postmortem

#207

Post by scott_s » Wed, Jan 18, 2017, 3:38 PM UTC

coffeemug wrote: post #32

Hey all, author here. FYI, the post is still in its unpublished state. It's basically right, but I've been meaning to edit it for tone and rewrite the market failure section for clarity. Didn't get the chance to do that before it made it on HN, so keep in mind that you're reading a (late) draft.

I hope my finished writing is as good as your draft.

Re: RethinkDB Postmortem

#208

Post by pfooti » Wed, Jan 18, 2017, 3:40 PM UTC

rogerbinns wrote: post #17

bcantrill wrote: post #10

Fascinating read, albeit a sad one: I love RethinkDB, and use it personally every day in our particular production deployment.[1] But -- and to Slava's point -- we didn't/don't/wouldn't pay for it, and in that regard, we were part of the problem. That said, the constraint on that particular problem was that it had to be open source, and if it couldn't have been RethinkDB, it would have been some other open source dat…

> ... the reality is that no one -- absolutely no one -- has built a business on AGPL software ... MongoDB server is AGPL - client drivers are Apache. To be fair the business side is based around larger scale deployment and management, and is proprietary add-ons. I'm kind of surprised that approach wasn't mentioned for Rethinkdb - a free open core product, with paid extras dealing with pain points in larger deploymen…

While I like that idea (paid extras to deal with pain points), it puts developers of the base product in a weird position. They are incentivized to ignore user complaints on one codebase, as that's a business driver on the other codebase.

Nothing new, just a strange place to be in.

Re: RethinkDB Postmortem

#209

Post by amalag » Wed, Jan 18, 2017, 3:41 PM UTC

jldork wrote: post #206

Yeah, my perspective is that Mongo just positioned themselves well in their marketing. They became a default option as part of the MEAN stack. I wonder if Rethink somehow piggybacked on React or Angular in the same way...

A part of their success was timing. When they came out I didnt know of anything else that could allow you to store JSON objects and do queries on them. Just that ability was a big deal. I believe the mainstream alternatives was to serialize your JSON object and store it in a text field.

Re: RethinkDB Postmortem

#210

Post by ryanbrunner » Wed, Jan 18, 2017, 3:46 PM UTC

andrewbarba wrote: post #199

Perceptes wrote: post #9

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,…

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 yea…

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.