3 ms·
How this article does not mention SSE, comet or chunking escapes me. What does their definition of event-driven really look like in practice. Nobody has a clu
by bullen 3y ago
How this article does not mention SSE, comet or chunking escapes me.
What does their definition of event-driven really look like in practice.
Nobody has a clue.
Here is the ideal event driven system, it's async-to-async: https://github.com/tinspin/rupy/wiki/Fuse https://github.com/tinspin/rupy/wiki/Fuse
The example is not working because I had to shut down the services for multiple reasons, but the high level of it is that you use 4 (potentially different) threads to do one request/response middle man transaction.
That way you have _zero_ io-wait or thread idling. I'm surprised nobody has copied this approach since I invented it 10 years ago. I understand why though you need your entire chain to be async and that means rewriting everything and that is a big risk when it's hard to debug.
But if you succeed you can build something that is 10x perf/watt than all other implementations. Which is going to be important when interest rates go higher and crash our entire industry.
- deleted 3y ago[deleted]
- anacrolix 3y agowtf is this shit
- hinkley 3y agoYou have the same problem that a number of my coworkers have had: there comes a point where someone is so bad at explaining themselves that you can’t tell if they have a really brilliant idea, or if they are so used to complecting things that they’ve taken something straightforward and wrapped it up in a baroque package. Sometimes such people succeed anyway, but typically when they find themselves surrounded with people suffering from Impostor Syndrome. Which is to say, people who think, “this is to complex for me, I must be too dumb” and not, “this is to complex for me, it must be too dumb” The problem with most really exceptional ideas is that, once said out loud, they sound completely obvious to most everyone else. If they come out early in a design process, people think you haven’t contributed much at all. They only see the value if the suggestions come after a plan has already started to wind itself around the axles. At which point the people suffering from Sunk Cost may push back because we worked so hard to solve this problem the hard way we’d feel foolish going back now. If you want people to understand what you’re saying, do the work. Maybe try reading some Feynman. Stop using contractions in your examples. Use bigger charts, and use charting types people in industry actually use, instead of inventing your own. Pull out a thesaurus and find more accurate words (but still at an 5-8th grade reading level). Software made of complicated ideas doesn’t scale on the human side. Because eventually you’re staring at fifty “simple” ideas that interact in very complex patterns. If the ideas start out more complex than necessary, you run out of runway (similarly if you try to dumb everything down with “All Xs are Ys” absolutism you end up with a hundred ideas instead of fifty, and did by the same sword). As simple as possible, but no simpler. And if you can’t explain your ideas to college freshman, you don’t understand the domain as well as you think you do.
- bullen 3y agoThanks for your input. I agree and already imagined an animation that would make it clear why async. on both ends of transition servers connections is useful. The sorry excuses of visualizations I have now are truly WTF. Also all links being out-of-order does not help. I just need to pick tools. Leaning towards animated .gif now. Edit: I fixed the example link atleast. It fetches data from the distributed db.