Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RethinkDB Postmortem

github.com

Post reply on HN
Print view View original

221–230 of 270 posts

Re: RethinkDB Postmortem

#221

Post by SadWebDeveloper »

notacoward wrote: post #203

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…

> if you have to pause to explain basic concepts before they get it then you've probably lost their attention and their business.

And this point of failure for many startups was beautiful represented/mocked in the silicon valley series of hbo: https://www.youtube.com/watch?v=Lrv8i2X3gnI

Re: RethinkDB Postmortem

#222

Post by jwr »

amelius wrote: post #126
jwr wrote: post #104

I am using RethinkDB in PartsBox ( https://partsbox.io/ ). I initially picked it because I wanted a JSON document database that has a correctly implemented distributed story. But later on it turned out that the realtime-push (changefeeds) functionality is actually fundamental for me. I used it to build an app where every open sessions gets instant updates. Right now I don't know what other database I could use, becau…

> Right now I don't know what other database I could use, because I found no other solution that supports this kind of functionality, especially in a distributed setting. Have you looked at Datomic? It's not free but I think it provides the functionality you are looking for.

Yes. In fact it would fit my app very well, because it's also written in Clojure, and I'm even using datascript on the frontend side.

But "$5000 per Year per System" is outside of my price range for the foreseeable future.

Re: RethinkDB Postmortem

#223

Post by SadWebDeveloper »

TBH i never heard about RethinkDB until they announce they were closing... it look solid but never heard from them, probably because from my POV, the database choices gets pushed by communities more than "educated developers" like for example, python devs like to to push postgresql over anything else, nodejs devs like to push mongodb over anything else, php devs like to push mysql over anything else, aspnet/c#/paste-any-ms-languanges-on-win32 like to push sql server over anything else and oracle was there before anything else (so pretty much everyone knows it), my point is that maybe RethinkDB needed a community niche that push the db rather than being the second choice for every community.

Re: RethinkDB Postmortem

#224

Post by nickpsecurity »

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…

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.

Re: RethinkDB Postmortem

#225

Post by raverbashing »

sanderjd wrote: post #205
raverbashing wrote: post #157

Earlier quoted context omitted.

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

> I found dynamic types required more bureaucracy (if I wanted to sleep at night) in the form of unit tests and precondition checks everywhere.

This merits clarification

Most of programming in dynamic typing should be implicitly statically typed. Know what you're passing. Obey the implicit (duck-typed) interfaces

Basically, don't just check "if it's a list do that, if it's one element do something else, if it's a number do another thing" - this is a beginner's mistake (and I did those)

Besides that, unit tests are a good idea, and if you want "compile type checking" in Python use Pylint (it's a good idea to use it regardless of your situation).

Though it's not so much static typing that sucks, it's its implementation in the Java/C++ way. Go and Rust make it better.

Re: RethinkDB Postmortem

#226

Post by jinjin2 »

jwr wrote: post #104

I am using RethinkDB in PartsBox ( https://partsbox.io/ ). I initially picked it because I wanted a JSON document database that has a correctly implemented distributed story. But later on it turned out that the realtime-push (changefeeds) functionality is actually fundamental for me. I used it to build an app where every open sessions gets instant updates. Right now I don't know what other database I could use, becau…

It is a very different model, but have you tried Realm?

It is more of an object model that a straight up JSON store, but it has some of the best notification features I have tried. You can observe both object and query results in realtime, and since the dataset is replicated to you it has zero-latency local access.

They used to only support mobile, but now they also have a node.js version for server side use.

In my opinion Realms observability is light years ahead of all the other offerings out there.

Re: RethinkDB Postmortem

#227

Post by tracker1 »

mannykannot wrote: post #189
cmdkeen wrote: post #138

Earlier quoted context omitted.

IT people try and "trip you up" because we've been burnt so many times in the past with systems that don't do what is promised by the sales people, don't integrate well and who stiff you during the implementation phase. HR people are some of the worst because everything is super secret and they don't want to get IT involved, then they go and buy a system that lets you insert a carriage return into the phone number fi…

And yet a bunch of them chose MongoDB (over something else, not just over RethinkDB.) Was there some point in time when it was the best option for a lot of people?

They were a fairly early entry into modern document databases. They offer sharding/mirroring, and have a really simple, relatively nice interface. In the end, they're a good (enough) fit for a lot of use cases. While RethinkDB imho is absolutely better, market share entropy counts for a lot. ElasticSearch is a similar product in the end, with lower consistency guarantees, that is another good fit for a lot of use cases. Cassandra (C*) is also a good fit for similar use cases, though more difficult to work with, it's also more tune-able to specific needs.

It really depends on what you need... Every non-sql database tends to sacrifice something for some performance gain... RethinkDB is as close as I've seen to one without sacrifice.

Re: RethinkDB Postmortem

#228

Post by desireco42 »

desireco42 wrote: post #67

I really can't read all this negativity. Seriously you guys need to snap out of it. You created something fantastic, a database that perfectly answers need of developers. Clearly you need to give it time and align your expectations with market. RethinkDB is fresh view on how databases can work and look, it provides level on goodness not seen before. Just continue building on it. Horizon is also awesome. Things don't…

To answer detractors and well meaning commenters. I understand the challenges, just this project have to go on.

Re: RethinkDB Postmortem

#229

Post by SamReidHughes »

willyk wrote: post #22

Thanks to Salve for writing an incredible retrospective. One thing I'd be curious to hear is whether the RethinkDB team feels they could have create the tool and potentially the company without taking on venture capital/investors (similar to PostgresSQL, which I don't think has taken on vc).

That would have been completely impossible.

Re: RethinkDB Postmortem

#230

Post by geoka9 »

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".

To me, Go's selling points have been numerous:

- Faster than python

- Statically typed/no runtime bundling requirements

- Easy access to concurrency/multicore scaling

- Excellent tooling and integration with programming text editors

- Great documentation

- Excellent standard library which you can treat as a continuation of your own program

- Great design with pragmatic choices (this one is subjective, I agree)

In short, there's nothing else like that out there. Without Go, I'd have been stuck with JVM, Haskell or Erlang for most of my projects. And I dislike all of them, so Go has been a godsend.

Incindentally, I also happen to enjoy working with Postgres and prefer it to any other database I've worked with (SQL or not).

Post reply on HN