Live data from Hacker News

RethinkDB Postmortem

github.com

251–260 of 270 posts

Re: RethinkDB Postmortem

#251
post #230

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

You haven't laid out any concrete selling points for Go over Haskell or Java beyond "I dislike all of them".

Can you come up with any intellectual rather than emotional reason for preferring Go?

Re: RethinkDB Postmortem

#252

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

NoSQL's only selling point is you don't need to learn SQL? Hardly true. Major Oracle shops aren't dumping them for Mongo/Couchbase/... because they're trying to avoid SQL. They do it for scalability, availability, performance, flexibility and more. I don't see that the facts in the real world back you up here. Not claiming NoSQL is a panacea. You're definitely making some trade-offs, and in many cases it's just the w…

I didn't say that was NoSQL's only selling point. I said that was MongoDB's only selling point.

Re: RethinkDB Postmortem

#253
post #201

Earlier quoted context omitted.

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.

So what can you do in Go that you couldn't do (without a lot more difficulty) in Java or Haskell?

Re: RethinkDB Postmortem

#254

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…

> but he introduced me to the concept of market vs. technical risk

This bit alone provided the right keywords to help me express some of the ideas in the essays I have been writing. Thanks for posting.

Re: RethinkDB Postmortem

#255

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?

Yes, there was a point it was clearly the best option. Qualitative it was easy to understand. The mongo Cli looked exactly like MySQL. And it's single node performance was decent.

CouchDB was super slow. Cassandra was amazing but a bit confusing. MongoDB made sense and worked.

Re: RethinkDB Postmortem

#256
post #30

Slava (coffeemug) is very brave to introspect publicly and whenever I interacted with him, behaved with greatest integrity and kindness. Unfortunately, his hypothesis here that devtools are a tough market does not ring true. Making a business is always tough, making one that does something new is even tougher. There are many tools and database companies doing extraordinarily well, from Atlassian to Cloudera to Docker…

I spent 1.5 years writing a ton of code using RethinkDB, and the last two months rewriting all the code (and more) using PostgreSQL. You are completely right , e.g., "For RethinkDB, it was wrong to try to force people to learn a new language to use a DB, when there are just tons of interfaces already, and the new language has incremental benefits over say SQL." rings very true. SQL is incredibly expressive and the to…

So I disagree with this. One of the things I loved about RethinkDB was the fact that it did away with SQL. The problem with SQL (in high transaction applications anyway), is that performance isn't necessarily reproducible, or determinable from the query. You are at the mercy of how the query optimizer decided fetch your data. The more complicated your query, the less you can can out reproducible performance.

With RQL you could very clearly determine how rethinkdb was fetching your data, and you knew it was going to get your data in the same way every time the query ran.

Re: RethinkDB Postmortem

#257
post #244

Earlier quoted context omitted.

> you start a fresh server, tell it some other server address to peer with, and it does the magic This is the one thing I ask of every database software, yet we still don't really have it. 90% of problems could be solved if there was a focus on the basics like easy startup, config and clustering.

SQL Server is almost that easy, but still doesn't handle schema changes well.

How so? Aerospike, ScyllaDB, Rethink, MemSQL, Redis are the only databases that get close to this.

SQL Server availability groups requires Windows Server Failover Clustering, which is not quick or easy.

Re: RethinkDB Postmortem

#258
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 o…

Yes, it looks really good — but it's a different kind of database (I think). From a quick glance, it's an embedded object database used mostly client-side, while what I need is a distributed server-side database.

Re: RethinkDB Postmortem

#259
post #230

Earlier quoted context omitted.

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

You haven't laid out any concrete selling points for Go over Haskell or Java beyond "I dislike all of them". Can you come up with any intellectual rather than emotional reason for preferring Go?

I can open a standard library definition and quickly understand what it does. If I try to do that with Scala or Java, my eyes just glaze over. With Go I often don't notice when I venture outside of my own program and into 3rd party library code.

Re: RethinkDB Postmortem

#260
post #259

Earlier quoted context omitted.

You haven't laid out any concrete selling points for Go over Haskell or Java beyond "I dislike all of them". Can you come up with any intellectual rather than emotional reason for preferring Go?

I can open a standard library definition and quickly understand what it does. If I try to do that with Scala or Java, my eyes just glaze over. With Go I often don't notice when I venture outside of my own program and into 3rd party library code.

It sounds like you just didn't out in the work to learn Haskell. The docs are fantastic, but they do assume you are willing to get over the learning curve.

I don't think you are really disagreeing with me - go does nothing new, just lower learning curve.

Post reply on HN