361–370 of 457 posts
Earlier quoted context omitted.
Red Hat's market cap is almost $15B and they're worth $2B. Definitely not incompatible.
This is like saying "the widget sells for $15 and the price is $2". I assume you mean they have $2bn in annual revenue?
It seems that unfortunately RethinkDB the company was architected in such a way that the success of their product, in terms of performance and developer experience, led to a decrease in revenue. This shutdown therefore goes a long way to say how talented and ethically correct the team was, something extremely evident in how they put correctness and reliability in front of performance. In short, RethinkDB is a very so…
Please dont make excuses for their failure. "Developer experience" and "performance" are never reasons for failure. What does lead to failure is - lack of mass adoption - they didnt solve a problem everyone had - lack of nitch adoption - they didnt solve a problem a few people had badly I can tell you 4 features that I view more important than change subscription - can run in any ecosystem - pouchdb/couchdb and water…
Going by the public information on their website, the only way the company was making money from its product was via support and training.
The problem with making money only with training and support is that it falls flat when the product and documentation are so well done barely anyone considers these things important enough to spend money on them.
Additionally the website doesn't really provide much information on these services other than a contact form. If you're not already in touch with RethinkDB devs, you're probably more likely to ask a local contractor or specialised training company for help instead of reaching out to RethinkDB.
By all appearances, RethinkDB has been pretty successful as an open source project. It has a strong and active community, it is well represented at meetups, conferences and podcasts, it has 16k stars on GitHub (MongoDB has only 10k, MariaDB and MySQL have only 1k each).
But the company was not able to turn any of those numbers into revenue. Downloads, GitHub stars and Twitter mentions don't pay to keep the lights on. A successful open source project does not equal a successful commercial enterprise.
Earlier quoted context omitted.
Please dont make excuses for their failure. "Developer experience" and "performance" are never reasons for failure. What does lead to failure is - lack of mass adoption - they didnt solve a problem everyone had - lack of nitch adoption - they didnt solve a problem a few people had badly I can tell you 4 features that I view more important than change subscription - can run in any ecosystem - pouchdb/couchdb and water…
Does RethinkDB not support transactions? I thought it did.
source: https://rethinkdb.com/docs/consistency/
However, certain operations on a single key, like incrementing a counter, are atomic.
Earlier quoted context omitted.
Please dont make excuses for their failure. "Developer experience" and "performance" are never reasons for failure. What does lead to failure is - lack of mass adoption - they didnt solve a problem everyone had - lack of nitch adoption - they didnt solve a problem a few people had badly I can tell you 4 features that I view more important than change subscription - can run in any ecosystem - pouchdb/couchdb and water…
Does RethinkDB not support transactions? I thought it did.
https://www.rethinkdb.com/faq/#are-rethinkdb-transactions-at...
Earlier quoted context omitted.
How many people in the world can work on a large DB, even with source? I am all for open source, but it doesn't make things like this is easy as some make it out to be. For example with Linux source, how long would it take me to fix a video driver bug? Perhaps a year?
His point is a little more subtle than that. When you're choosing a database engine to build your company on, knowing that it's open source provides some level of guarantee that someone will continue to maintain it if the company/developer folds, even if that someone is not you. Therefore, if you're the one building the database, open-sourcing it de-risks your product to your potential customers, to some extent.
I think, more important that whether or not the DBMS is open source, just consider how critical the DB is. If you can't live without it, stick with a DB that you can be virtually 100% sure isn't going anywhere soon. Save your experimentation with new products for the small and less-important stuff, and make sure the small stuff doesn't reach some critical mass before the DB vendor does.
Interesting, I expected ArangoDB close shop before RethinkDB. I found both nice and even built a product on top of rethink over the last twelve months. Guess I was blended by the hype :D
I would have guessed the same, just by amount of splash RethinkDB had on YC compared to Arango, but the truth is I MUCH prefer ArangoDB. Their AQL is a beautiful replacement for SQL. Javascript style query languages are what I hate the most about a lot of NoSQL Databases. The multi-model support is also really cool, i.e. not having to commit to graph/non-graph before even starting the project. Foxx I generally don't…
Earlier quoted context omitted.
> literally only a single numeric type that is a 64-bit float After dealing with JavaScript and Lua, I am ready to call this a complete anti-pattern. To be a good language, it must support at least one size each of machine floats and ints. To be really good, it should be possible for me to choose any size of machine-supported floats and ints. To be great, it should also support rationals, fixed-point and complex numb…
This anti-pattern -- floats as the sole numeric type -- goes all the way back to BASIC in 1964. It's just as bad an idea now as it was then.
It seems that unfortunately RethinkDB the company was architected in such a way that the success of their product, in terms of performance and developer experience, led to a decrease in revenue. This shutdown therefore goes a long way to say how talented and ethically correct the team was, something extremely evident in how they put correctness and reliability in front of performance. In short, RethinkDB is a very so…
Please dont make excuses for their failure. "Developer experience" and "performance" are never reasons for failure. What does lead to failure is - lack of mass adoption - they didnt solve a problem everyone had - lack of nitch adoption - they didnt solve a problem a few people had badly I can tell you 4 features that I view more important than change subscription - can run in any ecosystem - pouchdb/couchdb and water…
Wow. I was seriously rooting for them. I'm looking forward to Slava's posts about their challenges on the business side. There's a part of me that's angry that MongoDB - which some would say has made an objectively worse product - has succeeded. My initial thought is that MongoDB has done a way, way better job at SEO. The number of blog posts about RethinkDB pales in comparison to Mongo. I wonder if they got beat on…
Given that the market for document DBMS is pretty small to begin with it's tough to beat a 25x difference in budget unless you have a product that is a complete game-changer. It will be interesting to see Slava's analysis. Meanwhile I wish the team and RethinkDB users well. DBMS start-ups are damn tough to pull off.
Earlier quoted context omitted.
I believe this is because the Node.JS community still recommends MongoDB as the perfect database engine for their projects. There is even a name for their stack — MEAN, MondoDB + Express.JS + Angular.JS + Node.JS — which is kind of ironic because considering the rapid evolution of the JavaScript ecosystem having an acronym like that will make no sense in a couple of months since now people prefer React-like libraries…
FWIW I've been in the Node/JS community for a few years and I've honestly rarely seen MEAN or Mongo be mentioned outside of blogs and corporate Hackathons (where Mongo is usually a sponsor). Maybe companies use it (I rarely pay attention to what people do with Node at companies) but I'll bet it's because of "hype" and its apparent popularity. Most JS devs I follow or talk to use a SQL database and dislike Mongo.
Other popular contenders are similar "full stack" or "full featured" solutions like Sails, Meteor and Total.js.
This is generally a result of beginners to Node trying to find something that does everything instead of spending some time learning the basics with a library like Express and going on from there.