Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Callback Hell (2016)

callbackhell.com

Post reply on HN
Print view View original

151–160 of 170 posts

Re: Callback Hell (2016)

#151

Post by Chyzwar »

simplify wrote: post #149
antihero wrote: post #117

Earlier quoted context omitted.

You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).

This is correct. Race conditions are still the most common vulnerability in web applications. Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly: 0.0s - [1] Client 1: Apply coupon 0.0s - [2] Client 2: Apply coupon 0.1s - [1] Server to database: Is coupon marked as used? 0.1s - [2] Server to database: Is coup…

Nope, your ACID database will ensure that two writes in the same time for the same record will not happen. You don't even need to ask database if coupon is used. You just try to use coupon, if already used return message to user.

Node give you freedom from Thread Hell. You enjoy similar performance without locks, threads, synchronisation. Race conditions happen but mostly with cache invalidation where you can have limited consistency guarantees.

Re: Callback Hell (2016)

#152

Post by dahart »

hota_mazi wrote: post #144
dahart wrote: post #75

Earlier quoted context omitted.

> Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something . You could hide all async in a…

> > Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? > No. Yes. That's exactly what coroutines achieve. They transparently suspend and resume execution of async code in order to make it look imperative. See https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl... for a good example.

No. Making it look imperative and being abstracted away are two different things.

Co-routines are not imperative, and you cannot treat them as though they are, you still have to understand they're async to use them at all. That is not "abstracted away", that is syntactic sugar.

Furthermore, this syntactic sugar only works locally when examining your coroutines, or promises, or asyc/await code. You still have to trigger that async code from somewhere, and the place it's triggered is always mixing sync and async code, so you can't sugar coat all of it.

There is no getting around knowing and thinking about the async factors when writing async code. You cannot hide it with coroutines or anything else.

Re: Callback Hell (2016)

#153

Post by erikpukinskis »

dpweb wrote: post #49

The 'asynchonous problem' in JS is twofold. It makes it more difficult to reason about the program, and is hell on readability, and readbility matters. Support, maintenance, etc. The lack of an ability to structure async ops in a simple way is the biggest drawback in the language. Callbacks of course have the drawbacks mentioned. Sure, you can separate the functions, smaller functions and that too is preferred, but s…

I can't disagree with you more strongly. Async/await and promises both take control flow complexity, of which callback hell is a symptom, and sweep them under the rug.

Whereas before you had a clear (if convoluted and in need of refactoring) control flow, now with async/promises you shove it all into an invisible state machine, with transient data structures that are either hard to inspect (promises) or totally inscrutable (async/await).

No thanks. I like callbacks.

Here's my test: can you reason about what a function might do with control flow just by looking at its call site, not its source code? With callbacks you can. With async/await you can't.

Re: Callback Hell (2016)

#154

Post by weberc2 »

addicted wrote: post #112
weberc2 wrote: post #111

It's interesting that JS is still trying to figure out ways to make callback-based asynchronicity less-painful while Go managed to skirt the issue altogether. Go is readable, asynchronous and parallelizable largely without callbacks of any kind. Of course Go has its own problems, but I think they're largely orthogonal to its async story (i.e., JS could adopt Go's async strategy without adopting Go's more controversia…

JS became a language it was never meant to be not because of its merits, but because it is the language of the web. Go is the language it was always meant to be, and a significant part of that was handling async. Once async/await comes along, JS will have a really nice solution, and to be honest, I think it's pretty impressive that JS, with the history of its development, has been able to acquire new technologies of…

Async/await will be an improvement to be sure, but I think it still leaves a lot to be desired. In particular, I'm not a fan of bolting (a)synchronicity onto the function definition; instead, it's nice to be able to run a function in either a sync or async context. But yes, props to JS for continuing to improve.

Re: Callback Hell (2016)

#155

Post by dang »

mybrid wrote: post #66

callback, n: 1. a function passed as a parameter. asynchronous programming, n: 1. code written to manage interrupts, often called signals. This article is exemplary of why any educated and trained developer will not go anywhere near the Javascript community.

Please don't do the programming flamewar thing on HN.

Re: Callback Hell (2016)

#156

Post by paulddraper »

Chyzwar wrote: post #151
simplify wrote: post #149

Earlier quoted context omitted.

This is correct. Race conditions are still the most common vulnerability in web applications. Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly: 0.0s - [1] Client 1: Apply coupon 0.0s - [2] Client 2: Apply coupon 0.1s - [1] Server to database: Is coupon marked as used? 0.1s - [2] Server to database: Is coup…

Nope, your ACID database will ensure that two writes in the same time for the same record will not happen. You don't even need to ask database if coupon is used. You just try to use coupon, if already used return message to user. Node give you freedom from Thread Hell. You enjoy similar performance without locks, threads, synchronisation. Race conditions happen but mostly with cache invalidation where you can have li…

Right; you need to put your lock in the database, encoded as an index.

Re: Callback Hell (2016)

#157

Post by nojvek »

Promises solve callback hell. Async await makes it even cleaner.

I think the way author is explaining is weird. It's very hard to follow logic when functions are declared all over the place.

Re: Callback Hell (2016)

#158

Post by drewgross »

simplify wrote: post #149
antihero wrote: post #117

Earlier quoted context omitted.

You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).

This is correct. Race conditions are still the most common vulnerability in web applications. Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly: 0.0s - [1] Client 1: Apply coupon 0.0s - [2] Client 2: Apply coupon 0.1s - [1] Server to database: Is coupon marked as used? 0.1s - [2] Server to database: Is coup…

Calling race conditions the "most common" vulnerability seems like some pretty extreme hyperbole. What about SQL injection or XSS?

Re: Callback Hell (2016)

#159

Post by simplify »

drewgross wrote: post #158
simplify wrote: post #149

Earlier quoted context omitted.

This is correct. Race conditions are still the most common vulnerability in web applications. Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly: 0.0s - [1] Client 1: Apply coupon 0.0s - [2] Client 2: Apply coupon 0.1s - [1] Server to database: Is coupon marked as used? 0.1s - [2] Server to database: Is coup…

Calling race conditions the "most common" vulnerability seems like some pretty extreme hyperbole. What about SQL injection or XSS?

You're right, I meant to say the most commonly unaware vulnerability.

Re: Callback Hell (2016)

#160

Post by simplify »

Chyzwar wrote: post #151
simplify wrote: post #149

Earlier quoted context omitted.

This is correct. Race conditions are still the most common vulnerability in web applications. Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly: 0.0s - [1] Client 1: Apply coupon 0.0s - [2] Client 2: Apply coupon 0.1s - [1] Server to database: Is coupon marked as used? 0.1s - [2] Server to database: Is coup…

Nope, your ACID database will ensure that two writes in the same time for the same record will not happen. You don't even need to ask database if coupon is used. You just try to use coupon, if already used return message to user. Node give you freedom from Thread Hell. You enjoy similar performance without locks, threads, synchronisation. Race conditions happen but mostly with cache invalidation where you can have li…

The problem isn't "two writes at the same time", it's the server thinking everything's OK for two separate users.

If can model your database differently for this rudimentary example, then good for you – you're thinking about race conditions. Many web programmers do not think about them at all, and race conditions are usually not trivial to fix.

Post reply on HN