Async is good because threads are expensive, might aswell do something else when you need to wait for something anyways.
But only having async and no other thread when you need some computation is obviously awful… (or when starting anothe rthread is not easily manageable)
Thats why i like go, you just tell it you want to run something in parallel and he will manage the rest… computational work, shift current work to new thread… just waiting for IO, async.
The only way I have heard threads are expensive, in the context of handling many io requests, is stack usage. You can tell the os to give less memory (statically determined stack size) to the thread when it’s spawned, so this is not a fundamental issue to threads.
Go ahead and spin up a web worker and transfer a bunch of data to it and tell us how long you had to wait.
Time to transfer data to one thread is related to io speed. Why would this have anything to do with concurrency model?
Well I just told you another one, one actually relevant to the conversation at hand, since it’s the only one you can use with JavaScript in the context of a web browser.
No, because async is fundamentally a paradigm for how to express asynchronous programming, i.e. situations where you need to wait for something else to happen, threading is not an alternative to that, callbacks are.
Async is good because threads are expensive, might aswell do something else when you need to wait for something anyways.
But only having async and no other thread when you need some computation is obviously awful… (or when starting anothe rthread is not easily manageable)
Thats why i like go, you just tell it you want to run something in parallel and he will manage the rest… computational work, shift current work to new thread… just waiting for IO, async.
The “do something while waiting for something else” is not a reason to use async. That’s why blocking system calls and threads exist.
Threads don’t need to be expensive. Max stack usage can be determined statically before choosing the size when spawning a thread.
Any other reasons?
Well too bad cause they are.
Go ahead and spin up a web worker and transfer a bunch of data to it and tell us how long you had to wait.
The only way I have heard threads are expensive, in the context of handling many io requests, is stack usage. You can tell the os to give less memory (statically determined stack size) to the thread when it’s spawned, so this is not a fundamental issue to threads.
Time to transfer data to one thread is related to io speed. Why would this have anything to do with concurrency model?
Well I just told you another one, one actually relevant to the conversation at hand, since it’s the only one you can use with JavaScript in the context of a web browser.
You cant say async is the fundamentally better model because threading is purposely crippled in the browser.
The conversation at hand is not “how do io in browser”. Its “async is not inherently better than threads”
No, because async is fundamentally a paradigm for how to express asynchronous programming, i.e. situations where you need to wait for something else to happen, threading is not an alternative to that, callbacks are.
Threads are callbacks.