Monday, November 18, 2013

The reactive manifesto is 'not even wrong'

I am sure the authors and signers of the reactive manifesto are well-meaning people, but the entire tone and concept of the site is just wrong.

On a technical level, though, the reactive manifesto is too vague to critique. I could try to interpret and respond to some of the vague claims that seem wrong or silly (for instance, I detect some confusion between an asynchronous API and an asynchronous implementation), but then I fully expect defenders to define away the criticism or say I've misinterpreted things. Its arguments hold up only by being not even wrong.

When you cut through the bullshit, it seems the only actual information content are inane or tautological statements like "being resillient to failure is good" and "one shouldn't waste OS threads by blocking". Do we really need a manifesto to tell us these things? Of course not.

But the point of the reactive manifesto is not to make precise technical claims. Technical arguments don't need manifestos or rallying cries. Imagine the ridiculousness of creating quicksortmanifesto.org to rally people around O(n*log n) sorting algorithms as opposed to O(n^2) algorithms.

Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.

In the reactive manifesto, one is invited to join a movement and rally around a banner of buzzwords and a participatory, communal cloud of vagueness. Well, I don't want to join such a movement, and the pop culture and tribalism of our industry is something I'd like to see go away.

I would welcome some interesting precise claims and arguments (that aren't inane truisms) about how to build robust large systems (there may even be the seeds of some nuggets of truth somewhere in the reactive manifesto). But let's not make it a manifesto, please!

Update: I recently received a note from a recruiter, which contained the following gem:

We checked out your projects on GitHub and we are really impressed with your Scala skills. Interested in solving hard problems? Does designing and building massively scaling, event-driven systems get you excited? Do you believe in the reactive manifesto? Let’s talk.

While I agree with many of the principles espoused within it, I don't see a coherent thread that connects them. Instead, to me it comes across as a bundling together of many disparate techniques that are presently popular.

I think you read too much into it.The reason we dont need a quicksort manifesto is because using incorrect sorting algorithms isn't what causing systems built today to fail.Alot of devs don't even know what different sorting argorithms there are, they use what the tools and frameworks give them.

There is however a big problem with how we build systems today, and when I say "we" I don't mean the know it all computer science guys, but the average joe dev doing consultancy or working inhouse, building LoB applications based on the same 3 layer architecture with request response style API's that them and their mentors have seen as best practices for the last X years.These guys will not change the way they build systems unless someone show them a better way, and for that to happen, we need a movement, a hype, call it what you want.It has to become trendy or hip before it becomes mainstream, DDD, NoSQL, CQRS etc, all of those have been hyped and are to various extents mainstream today.

I read the post from Øyvind Teig, ofcourse it would be better to have systems that never fails than to use supervisor modules that deal with failure, ofcourse!But, you arn't going to see the average joe dev produce such a system in any near future.

The reactive manifesto, even if it is pop-culture and marketing hype from the backing people to sell their services, is needed to bring these concepts to large mass of developers.

wonderful post, cannot agree more. Also, what Roger Alsing says: "The reactive manifesto, even if it is pop-culture and marketing hype from the backing people to sell their services, is needed to bring these concepts to large mass of developers" confirms Alan Kays assertion that lack of education is one issue. I consider myself educated, so I am NOT part of the target audience of the manifesto, it seems

I found your post valid but as empty as the manifesto. From one side I agree with you that the manifesto is weak and vague but the essential aspects of it are a very good driver to take in mind. You might find all of that obvious but I found many developers who don't and keep using sync and blocking operations for highly available and intensive systems. I consider that you should have published what you consider as valid manifesto instead of just claiming to be good enough with no need for such a document.

I still think your blog is good don't get me wrong but I like pragmatism and constructive approaches rather than just disqualifying without any added value rather than just personal opinions and few quotes (better facts instead).

I don't think the manifesto is BS. As much as you say that its stuff that should be known, the fact is most developers I've encountered actually have no concept (I do work in an environment with lots of "juniors"). I certainly don't see it applied in most development frameworks I've encountered. I also think its actually a really good way of explaining some technical concepts without getting into to much technical detail. Agree whole heartedly with Alex's post above.

I disagree. I believe the intention is to provoke thought on the concepts and patterns to be considered in both functional and non functional large scale systems. The principles are sound, why not consider resilience? This is not a how to guide, its just a guide. Think about these concepts when you endeavour on modern systems. That's it. Its not a mantra