71–80 of 117 posts
https://github.com/scalien/scaliendb/blob/master/src/Framewo...
I guess the OP is saying inlining [in a language where this is even possible] leads to unreadable code, which sounds about right.
If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…
This is a pretty common pattern for any work you have to do asynchronously, pretty much all libraries should be implementing this for you so the first 3 lines should be all you code getSomething("id", function(thething) { // one true code path }); function getSomething(id, callback) { var myThing = synchronousCache.get("id:3244"); if(myThing) { callback(null, myThing); } else { async(id, callback); } } a minor quibbl…
I was under the impression that you could not do _anything_ synchronous? What if the call blocks for 100ms? or 1000ms? Won't that delay all other clients and all other requests?
In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…
> I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed. I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and…
This holier-than-thou attitude is exactly the thing that prevents more people from becoming educated on these kind of subjects. Knowledge and experience on these kinds of subjects are _not_ trivial and are _not_ easy to obtain! Information about what scales, what does not, and why, are scattered all over the place and difficult to find. It may be very obvious to you after you already know it but it's really not. If, instead of spending so much time on declaring other people as dumb or uneducated, people would spend more time on educating other people, then the world would be much better off.
Earlier quoted context omitted.
the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.
I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?
4000+ requests being sent every second to the server in total, the server is a single node process.
My experience (mostly in perl - EV,AnyEvent, etc.) is that combining evens with finite state machines gives more structured code, with smaller functions that interact in predefined manner.
Earlier quoted context omitted.
I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?
If I can run one app with 10,000+ concurrent requests on one server, then I can run a hundred apps with a hundred concurrent requests each on that same server. You can say that doesn't matter either, but the cost of hosting a web app just dropped 99%.
The cost of hosting a webapp tends to be a rounding error in contrast to the cost of developing the webapp.
It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier. To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what…
Here's a library in JavaSCript that does this. https://github.com/kriszyp/promised-io The differences between your example and the common JavaScript practice for promises (when they're used; most of the time they aren't) are that then is used instead of addCallback and that chaining is available and taken advantage of.
Earlier quoted context omitted.
Here's a library in JavaSCript that does this. https://github.com/kriszyp/promised-io The differences between your example and the common JavaScript practice for promises (when they're used; most of the time they aren't) are that then is used instead of addCallback and that chaining is available and taken advantage of.
What do you mean by 'chaining'? Twisted's Deferreds provide at least a couple of things one might casually describe as 'chaining'.
d.then(func1);
d.then(func2);
d.then(func1).then(func2);