GordyMD

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.

See the FAQ http://horizon.io/faq/

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])

[1]: https://workshape.typeform.com/to/SGxTdw

[2] : http://psr.iq.harvard.edu/files/psr/files/PSRQuestionnaireTi...

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.

That would be a good addition. We'll consider adding it in later iterations for sure. Thanks.

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

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.

[1]: https://github.com/rethinkdb/rethinkdb/issues/1493

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 think if you take a lot at the motivations that Dan Abramov had for creating Redux [1], you'll see that improving debugging was at the centre of it. Check out his talk he gave at React-Europe. He basically is talking about improving developer tools. The functional approach Redux takes allows for you to see state transitions and replay actions - making it relatively trivial (compared to say Angular.js) to understand how to reproduce a buggy state.

[1] https://github.com/rackt/redux

[2] https://www.youtube.com/watch?v=xsSnOQynTHs

Fair point. I didn't really give this layer too much thought considering the focus of the blog. It could really be any Node.js framework.

Although saying that, if I had chosen Koa.js the stack would have to be called 3REK, or 3RKE :/

To demonstrate this point for those not familiar. Here is an example of using React + Redux on the server to render with an initial state.

https://github.com/GordyD/3ree/blob/master/server/universalA...

The video intro to the new interface is incredible, almost mesmerising. I really like the use of the circles from the new logo to symbolise key points and draw the eye to certain things.

Was this done in-house, or by a third party?