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

161–170 of 170 posts

Re: Callback Hell (2016)

#161

Post by nickik »

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…

ClojureScript compiles to JavaScript and you can have the exact same CPS style programming, with the exception of missing parallelism of course.

Async/await are not really what you want either. There is no fundamental reason JS could not have added a CSP model.

Re: Callback Hell (2016)

#162

Post by z3t4 »

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…

This is a problem in the database layer, not NodeJS!

Re: Callback Hell (2016)

#163

Post by z3t4 »

increment_i wrote: post #8

As a curious and perhaps naive aside, I've been wondering why the programmer should need to care about asynchronous execution of code at all. Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? The advent of promises, async.js, and other paradigms tell me that people still kind of want to write code that does one thing after another, then another, then another.

For most people thinking in the fourth (time) dimension should come naturally. It becomes complicated when there are multiple time-lines (threads) though, but JavaScript only has one time-line. You can have multiple time-lines in JavaScript via child processes and web workers though.

Re: Callback Hell (2016)

#164

Post by insertnickname »

tluyben2 wrote: post #43
insertnickname wrote: post #11

Earlier quoted context omitted.

That's how it's done in Go. You write plain, "blocking" code, and if it blocks, the Go runtime will just schedule another goroutine (green thread). In Go there's no need for callbacks or littering your code with `await` keywords to write concurrent software.

I never checked that out but ; https://www.golang-book.com/books/intro/10 looks messy to me. Less messy than callbacks but more messy than async/await imho. Maybe there are nicer examples? Also I agree with the coroutine LUA rationale you can read in the link in this same thread. It appears that with Go I still need to alter my own code to use libraries that are written to run async or am I wrong?

You may also be interested in this blog post: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re: Callback Hell (2016)

#165

Post by Matthias247 »

hashkb wrote: post #99
lucideer wrote: post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

Are there JS runtimes that are primarily synchronous? Certainly not any popular/widely used ones. Asynchrony is for all practical purposes a property of JS.

You can run Javascript on the JVM with Rhino and Nashorn. There you have access to all the classical synchronous Java APIs - and you need to care about synchronization and real multithreading, which is not really javascripty.

Re: Callback Hell (2016)

#166

Post by tluyben2 »

insertnickname wrote: post #147
tluyben2 wrote: post #43

Earlier quoted context omitted.

I never checked that out but ; https://www.golang-book.com/books/intro/10 looks messy to me. Less messy than callbacks but more messy than async/await imho. Maybe there are nicer examples? Also I agree with the coroutine LUA rationale you can read in the link in this same thread. It appears that with Go I still need to alter my own code to use libraries that are written to run async or am I wrong?

>Less messy than callbacks but more messy than async/await imho. Maybe there are nicer examples? That book chapter doesn't really illustrate the utility of Go's concurrency very well, it just explains the basic components that make it work. Let's say you wanted to fetch three text documents via HTTP and print each of them. Here's the regular, blocking way to do that (error handling, package imports, etc. omitted for…

Thanks!

Re: Callback Hell (2016)

#167

Post by novaleaf »

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…

agree. the coupon problem would be best fixed with atomic database transactions.

in fact, an entirely synchronous, 1-user-at-a-time server wouldn't fix this, if there were two or more servers. and honestly, who would design any system that only supports 1 concurrent user?

Re: Callback Hell (2016)

#169

Post by friendzis »

novaleaf wrote: post #113
lucideer wrote: post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and compl…

The claim about line 2 executing right after line 1 breaks for any program running in concurrent context. Which is probably every nontrivial program dealing with side effects ever written, does not really matter whether that is C#, C++, JS or bare metal assembly.

> something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread

If your runtime (kernel, VM, etc - not "user code") has theoretical possibility to change user memory/variable (call user code) concurrently, there is theoretical possibility to have race conditions. Concurrent runtime must have certain entry points to user code and everything that can be theoretically touched from these entry points must be treated dirty, which can get pretty expansive with complex callbacks. The only way to NEVER* have race conditions is to use polling - explicitly mark memory dirty (semantically in code) between "synchronisation points" having only flags/counters (in my view they are the same) for communication between userland and runtime.

* If we allow for settling time and do not treat situations "read flag --> have flag value flipped --> execute based on old flag value" as race conditions.

Re: Callback Hell (2016)

#170

Post by Can_Not »

simplify wrote: post #160
Chyzwar wrote: post #151

Earlier quoted context omitted.

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.

> Use ACID compliant Database or not

How is that specific to only NodeJs?

Post reply on HN