I'm very upset to hear this. RethinkDB, and the team behind it, have been inspirational to me and it has transformed my day to day development workflow. Their dedication to developer experience (amazing docs, ReQL, admin tool,...) has been something I've particularly admired. I'm relieved that the team has a new home though and it's fantastic that a company that has similar traits is the destination - props to Stripe and the RethinkDB management team for making this happen.
I hope to see RethinkDB to live on in the OS community.
For convenience, this is the section taken from it that addresses this exact question! (I imagine other people may be thinking this)
How is Horizon different from Meteor?
Horizon has philosophical and technical differences with Meteor that will result in vastly different developer experiences.
Horizon is a small layer on top of RethinkDB with a narrow, purpose-built API designed to make it very easy to get started building realtime apps without backend code. Horizon isn’t prescriptive – you can use any front-end framework without any magic/customizations, and once your app outgrows the Horizon API you can use any backend technology (e.g. Node.js, Python, Ruby) and any backend framework (e.g. Rails, Express, Koa, etc.)
By contrast, Meteor is a much more prescriptive framework. Horizon is a reasonably small component that has a very clean separation with the database and the frontend, while Meteor is a much more monolithic experience.
Another major difference is architectural – Meteor uses a LiveQuery component built by tailing MongoDB’s oplog. This approach is fundamentally limited – it’s impossible to do many operations efficiently, and even the basic functionality is extremely difficult to scale.
Horizon is built on RethinkDB, so the LiveQuery functionality is in the database. This allows for much more sophisticated streaming operations, and scalability is dramatically simpler because the database has all the necessary information to allow for a scalable feeds implementation.
CTO of Workshape.io here - we are a hiring platform for software engineers that's primary focus is matching developers to opportunities based on your passions and how you want to spend your time in your next role. When you match with a position you interface directly with someone at the company without any mediating through recruiters. Added bonus: there is no need for uploading your resume/CV!
With 2 of the founders being developers we can relate to the level of recruiter spam in this space and so we created Workshape.io to cut through the noise and make meaningful intorductions between developer and company based on shared requirements.
We have about 200 postings on the site right now spread across the globe, but mainly concentrated in Europe. That said though, we do cater for people seeking remote work + relocation so if you fall under that remit then you may find us even more useful.
Would love for you to check us out and would welcome any feedback.
My team and I at Workshape.io are working hard to build a hiring platform for software engineers that addresses some of the various shortcomings in this space.
We have noticed over the past few weeks that interviewing techniques and hiring standards have been a hot topic on HN. We are interested in finding out from the community what your limits are when it comes to interviewing as we feel there is little understanding of this - We all have our opinions on what is effective but it would be incredibly useful to identify trends across different demographics in our industry.
We have created a quick survey [1] (that is anonymous) to help us gather information so that we can produce a report for the benefit everyone. It shouldn't take much longer than 10 minutes to create. We'd be incredibly grateful for any contributions. (The survey has been designed with attention paid to a survey designing guide from Harvard [2])
I can totally relate to the impact of FM on my life. I'm CTO of Workshape.io and some of our UI elements were inspired by the interface that was present in some of the older versions of Football Manager and Championship Manager. The concept of the radial plot for comparing player's skills was an idea we applied to our matching service.
To echo the parent poster's comment. It would be very cool to extend this blog into a series and see an analysis like this applied to the most recent version of Football Manager.
It is very encouraging for myself, CTO of a company that uses RethinkDB, to see the efforts that RethinkDB go to ensure quality in their product and the willingness to allow Aphyr to potentially uncover problems lurking under the surface.
Thanks again to Aphyr and the team at RethinkDB for going to such lengths to discover, document and fix such failure conditions. Going to have to read through this thoroughly tonight.
I just downloaded the Mac OS X version to try it out and upon clicking 'Demo Mode' I am presenting with the next screen which is mostly blank (Screenshot: http://i.imgur.com/evyyF5v.png).
That's a bummer. Sadly, I don't have any guesses as to why. I'm happy to help debug if you want: nick@realartists.com, but understand if you don't want to spend any more time on it.
Great to finally see a write up by Aphyr on RethinkDB. Ever since reading these blogs and seeing RethinkDB lost standing Github issue [1] I was keen to hear how RethinkDB would hold up to the tests once RAFT was implemented.
Given the thoroughness of the Jepsen test suite it is something people want to see these days before being able to choose a database with any confidence. Hopefully this sets out expectations with high transparency.
Kudos to the team at RethinkDB for funding and assisting Apyhr in his work.
> Given the thoroughness of the Jepsen test suite it is something people want to see these days before being able to choose a database with any confidence.
Definitely agreed on the "something people want to see" part, but this is this is the thing... Jepsen isn't actually that thorough[1]. I rather think that this is an indictment on the state of "practical" distributed computing as it currently stands that a "simple" test for linearizability (nowadays) or even simple CAS (which I believe Jepsen started out testing) in a partitioned system would turn up such a huge amount of badly implemented distributed systems and... frankly dishonest documentation around those systems.
It's not that I could necessarily do any better -- except maybe the "honesty" part, or at least adding lots of qualifiers -- I just find it a bit... sad in a way that we haven't come farther. Still, it is a young field, so there may be grounds for optimism for the future. (Thinking of e.g. dependent type systems coming together with model checking coming together with verified model->machine translation, chips with verified semantic models, etc. etc.)
[1] As Aphyr explicitly states, it's actually very limited in the state space that it can explore simply because it's constrained to be "external" to the system being tested. Model checkers can do much more -- but then you usually don't get a fully automatic and verified translation to machine code... and who knows if you've modeled the CPU/IOMMU/etc. correctly anyway?
EDIT: Btw, Aphyr deserves a HUGE amount of praise. AFAIK he's the only person so far who has stepped up to the plate and "dared" to actually test this stuff. It's kind of amazing in a way, but I think I'll blame corporate culture for this sort of thing... "Oh, the documentation says $X therefore we'll believe $X. At least they can't fire us for that." Not surprisingly I was known to be hugely skeptical of any claims made of distributed systems, but I was too much of a coward to embark on "Aphyr's Quest" :). I'm hoping to coin a phrase with that last bit.
A very important point, and true of anyone holding any form of seniority in a position, but especially as a team lead. Always remain humble and accept that your team can have abilities and understanding beyond yours.
But, as an alternative to 3, and possibly an extension of 4, when you have an idea/experience of a solution to a problem but your team does not, create a dialogue whereby your questioning of their approach allows them to find your solution by themselves. You can pass on skills and techniques you've learnt in a manner where they learn them too rather than being told of the solution. Your team will feel proud of their solution and you can be happy knowing you are cultivating a strong learning environment.
I hope to see RethinkDB to live on in the OS community.