Reactive Manifesto

http://www.reactivemanifesto.org/

by satyampujari • 13 years ago

59 45 13 years ago

w_t_payne2• 13 years ago

Horses for courses. Async. architectures are great for distributed back-end systems (God I love making streaming data-science applications) ... but not so great for on-the-metal embedded devices; where static & limited computational capacity & whole-system predictability requirements drive you in the opposite direction. I do a lot of machine vision stuff for embedded systems, and having everything driven by the drum-beat of a frame interval really does simplify things a lot; particularly when it comes to finding the absolute cheapest hardware that will be able to perform a given function.

tlarkworthy• 13 years ago

I read this awesome book and multi threading embedded systems. "Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems"

The author has an amazing stack for psuedo real time scheduling on seriously limited hardware, http://www.state-machine.com/ . QP-nano brings async real time to PIC processors! So there really is little overhead for async architectures. I think async squeezes more out of limited hardware by avoiding busy loops waiting for IO or other synchronizations to align.

I agree its more difficult to develop with async, but I strongly disagree going non-async saves you money on hardware

w_t_payne2• 13 years ago

It's not really about the overhead. The intrinsic overhead of async. is trivial, anyway. It is more about predictability & how the system is understood. Async architectures let you have simple, easy-to-understand components, but the expense of a more complex macro-control-flow. Hardware and embedded guys spend a lot of time looking at storage 'scopes, and like things to be nice and periodic... it just fits in with the world-view a bit better. It is not so much that one is objectively better than the other, it is just about how different people's mentality works.

davidw3• 13 years ago

So basically... Tcl. Which got all of that years and years ago. Except of course 'scaling', which doesn't make a lot of sense for the desktop environment it was created in. Actually, come to think of it though, it did get that too, via AOLServer.

girvo• 13 years ago

I'm really curious about this, do you mind expanding on it?

zenojevski2• 13 years ago

I've always been fascinated by TCL, so I second girvo's request. I'd like to know more, with possibly some links to in depth resources, or some insight (as TCL is not that "in" nowadays).

golergka2• 13 years ago

Whoever created this page obviously never tried to resize the viewport to something like 320 by 240.

zenojevski2• 13 years ago

Yes, please! http://i.imgur.com/yMzh9jQ.png

EDIT: It's nothing more of a joke... What if we had Deluxe Browse II?

But more seriously, who browses in 320x200? Does anybody follow 256-color web-safe palettes anymore?

golergka2• 13 years ago

http://i.imgur.com/NJLwLCb.png

JetSpiegel• 13 years ago

The Reactive Manifesto page can't react to resizes. Oh the irony.

iamwarry3• 13 years ago

I did, and I didn't.

Sorry, but I've never seen this resolution in my analytics logs. Next time I'll think about it ;)

bhauer2• 13 years ago

Also please target Lynx, Mosaic, and Netscape 2 in the future.

z0r• 13 years ago

I made a new diagram they can add to this "manifesto" if they like - http://i.imgur.com/ll51WJ3.png

blatherard• 13 years ago

Reference for those that don't get it (I had to look it up): http://www.timecube.com/ Original image appears about 1/3 of the way down.

ChikkaChiChi2• 13 years ago

I think...well, I know...I just...

What?

angersock• 13 years ago

wait wait wait where did you get the internal documentation for express?

dschiptsov2• 13 years ago

Nice moment for the pioneers, such as Joe Armstrong. Seems like they finally got understood. There would be no Scala without Erlang and no such paradigm without Martin Odersky. I am happy and grateful that I could read their books and use products of their efforts.

pessimizer• 13 years ago

http://www.reactivemanifestomanifesto.org/

smandou• 13 years ago

Hm, the reactive manifesto doesn't say that it's new. It tries to convert people from bloated ol' Java/CSharp to better practices that fits new common needs. Of course Reactive is not new... Nor realtime... But an ecommerce website for instance never had to wonder about this kind of things before: new needs.

bowlofpetunias• 13 years ago

Apparently written for the sole purpose of feeling superior to the 95% of all developers who's applications in no way, economical, practical or otherwise, justify such architecture astronautics.

Yes, there are applications that needs this, and I love to read about them, and learn from them. From real world solutions for real world problems that is. Not via some arrogant abstract this-is-the-one-true-path manifesto.

forgottenpass• 13 years ago

I've been reading to learn about tech for over a decade. It used to be the case that anything that didn't make sense was a sign that I'm a dumb baby and need to learn more. As I progressed and started exploring beyond dense technical tomes for knowledge, I've learned the hard way that other people's standards for what they would publish online in a professional capacity are lower than I assumed. They could actually just be talking out of their asses. That if a webpage is full of buzzwords written loftily, the purpose is to dupe me, regardless of whatever the distilled 1-paragraph version of that would say.

al2o3cr• 13 years ago

"It works best if the compartments are structured in a hierarchical fashion, much like a large corporation where a problem is escalated upwards until a level is reached which has the power to deal with it."

Because when I think "effective, responsive, and scalable decision-making", I definitely think "big ol' ORG CHART", amirite? /snark

sramsay• 13 years ago

There's nothing like the fiery, strident rhetoric of a manifesto to get one's heart pounding.

"Application requirements have changed dramatically in recent years."

I mean, if that doesn't make you want to lose your chains, I don't know what will.

saryant2• 13 years ago

This talk by Jonas Bonér (one of the Akka devs) covers the motivations behind this well: http://parleys.com/play/51c0c876e4b0d38b54f461f6/chapter0/ab...

btilly2• 13 years ago

My first reaction to reading this? If you follow this design in the way that they say, you're going to wind up with a confusing mess with no visibility into why your buzzword compliant application is dog slow.

Very carefully thought out and pervasive monitoring is an under-acknowledged but utterly essential part of Google's recipe for success.

the_af2• 13 years ago

First reactions can be misleading. I'm currently taking the Reactive Programming course by Martin Odersky and Erik Meijer, over at Coursera, and one of their stated goals is to reduce complexity, specifically the complexity of what they call "callback hell".

Not sure if Reactive Programming achieves this lofty goal, and buzzwords are always annoying, but I'd be wary of dismissing RP out of hand.

(I'm still undecided on its merits, by the way)

arethuza• 13 years ago

Personally, I found the outline of the Coursera course you mentioned a lot more interesting than the "manifesto":

https://www.coursera.org/course/reactive

disputin• 13 years ago

Reduce complexity? In the second week of the course they removed the submission limit and doubled the submission window. The forum was a mass head scratching.

Edit:

How can you down vote an observation? Feel free to comment instead. I enjoy Scala, which is why I joined the course, but I thought the above added weight to the argument that Scala is too complex/academic/etc.

btilly2• 13 years ago

Yes, they aim to reduce the complexity of the code.

The issue is what tools you have to dig in when you're asked, "Why is this page taking 5 seconds to load?" With a traditional single threaded application there is the inherent simplicity that you can profile it, look at timings, and see where the performance went. With an asynchronous distributed application, you have to do a lot more work to start digging in.

The reason why this matters is that there are always some boneheaded performance mistakes. They would be trivial to fix if you only knew what to change. Without visibility, you won't be able to find where they are - you're just stuck suffering the consequences.

I'm definitely not saying that this is impossible. Far from that - Google succeeds brilliantly. But the kind of behind the scenes pervasive visibility that you need is an essential component, and it is not something that happens by accident or is trivially retrofitted on.

bachback• 13 years ago

here is my manifesto: react to everything and you're slave. create reactions and you're ruler. balance action and reaction and you're a master.

platz• 13 years ago

Some thoughts about manifestos in general:

"A manifesto is about moral authoritarianism: an absolutist statement of eternal values from which follows (typically) an absolutist ideal of the good life. If there is one thing that most defines a manifesto, it is what it lacks: a central place for uncertainty."

"The problems Haque identifies cannot be solved with manifestos because they are problems, not karmic punishments for espousing false values that will go away through the embrace of the “right” values."

http://www.ribbonfarm.com/2013/11/13/the-gooseberry-fallacy/

jblow• 13 years ago

I like the broad idea (applications should be very responsive). Yes, this is very important, but I can't shake the feeling that the author of the manifesto has very little experience with responsive software (or even with software generally).

For example, the manifesto confuses ends with means. It states a desired end, but then claims that certain means are required to get there (for example, "event-driven"). Maybe event-drivenness can come into play in a given system, maybe it shouldn't; across a broad set of domains this is orthogonal to the concept of responsiveness.

In video games, for example, we do things that are extremely responsive compared to web stuff (last week I worked on something that had to run at 200 frames per second in order to meet requirements). Interactive 3D rendering systems are most certainly not event-driven; they derive their responsiveness from cranking through everything as quickly as possible all the time.

There are lots of different domains of software out there and they all have found different local attractors with regard to what techniques work and produce the best result. Web software is just one of these domains, and frankly, it isn't doing so well in terms of quality compared to some of the other ones. So I think if one wants to write a manifesto like this, step one should be to get out of the Web bubble for a while and work hard in some other domains in order to get some breadth and find some real solutions to return with.

mmcnickle• 13 years ago

The people behind the reactive manifesto are typesafe.com

Unsurprisingly, they have products to sell that are manifesto-compliant.

joostdevries• 13 years ago

I found out that a build I was doing was utilising http://imgur.com/U70Rcrz. I don't see that very often. Personally I find that kind of parallel processing CS magic impressive. Similarly I like the possibility of processing data as it arrives in a non blocking fashion in pipes-and-filters chains of computation. Another thing I like are having arbitrary numbers of stateless possibly short lived servers. Like you see at PaaS's like Heroku. Easy load balancing, easy recovery. These are all things that become possible by employing other programming paradigms than the classical thread based, blocking, stateful ones.

And it's not confined to one tech stack either; .net, javascript, java, scala, ...

To me it's just good computer science for when you want to be near real time, scale horizontally and utilise your hardware resources and be able to handle failure.

ChikkaChiChi2• 13 years ago

'Show your support with a ribbon' that breaks when the site goes responsive.

Reactive Manifesto

Related Stories